нейронки выйдут из эмбрионального состояния, и всякоразные Плюсы с Питонами уйдут в нишу автокода.

при наличии фейла и следовательно для выявления его причины легче разобраться в чёткой логике, описанной формальным языком с формальной грамматикой, чем в его формальном описании на нечётком человеческом с множеством потенциальных неточностей, неоднозначностей и недосказанностей и местами противоречий, что не были замечены на извиняюсь спринтах.

Вот есть скажем требование что размер формы должен быть 100x200, вполне себе нормальный сценарий, который тоже можно протестировать. Или скажем "в случае неудачного соединения N-раз должно выскакивать окно - "Подключение невозможно, проверьте параметры сети", которое должно располагаться по центру экрана". Вполне себе нормальный сценарий, который тоже можно протестировать. Ага?

Вот начинаем мы какую-то новую штуку кодить по TDD. Мы начинаем же с самых высокоуровневых задач? Т.е. сначала пишем тест на высокоуровневую задачу, верно? Потом, при развитии, проверяемая такими тестами функциональность в любом случае будет раскидана по нескольким юнитам. Так вот вопрос, эти более ранние тесты становятся интеграционными? Ведь у каждого юнита появится свой тест.

И долго еще осталось погождать?

Осталось понять, как правильно писать интеграционные тесты в C++ :D

Вводится дополнительный класс с дополнительной логикой.
...

Ну вот представим, что у тебя есть 2 компоненты: калькулятор и логгер. Все действия калькулятора должны быть запротоколированы. Как должен выглядить идеальный юнит-тест суммы?

Я уж как-нибудь обойдуть одним объектом, который полностью описывает "пользователя" и не буду убиваться из-за некоторой избыточности

В подавляющем случае как раз нет и в 99% случаев функция не использует все поля.

Просто из-за того, что никто не будет шлепать отдельный объект ради каждой функции.

В данном тесте - последний параметр - это заглушка и, соответственно Request - это мок-объект.

final var response = subject.submit(new Transfer.Request(
money,
() -> sourceAccount,
() -> destinationAccount,
() -> { /* e.g. do nothing in this particular test case */ }
));

Я не переписываю, я пытаюсь объяснить тебе, болезному, в чём разница между чистой функцией и объектом.

Если они требуют разные входные данные, то, естественно у них будут разные типы аргумента. А ты что, клепаешь God object'ы?

В подавляющем большинстве случаев — да. Если функция не использует какие-то поля, то зачем эти поля нужны? Для красоты?

Или все другие функции должны точно также как и submit использовать все поля Request'а?

Я думал, что ты тут пытаешься избавиться от моков

Изменится то, что ты уже 2-й раз переписываешь свой код и все это ради того, чтобы не было моков.

Если в данном случае и можно вынести в статический метод (т.к. функция примитивна), то нельзя гаравтировать, что вынос в статику будет работать в любом случае.

Или если у тебя 10 функций, то ты шлепаешь свой Request для каждой?

Так чтобы каждая функция использовала все публичные поля своего Request'а?

Ну тебе ж не нравилось, что я вызываю простую чистую функцию. Вот тебе альтернативное решение.

И что? Если они будут внешние, что принципиально изменится?

Ну вынеси их в статику

Он говорит, что в классе не должно быть десяток каких-то функций, не имеющих отношения к классу.

а, скажем, доступ к файловой системе нужно.

Ты понимаешь, что вместо вызова некой функции (в данном случае canWithdraw) ты предлагаешь создать некое поле, которое должно заполняться гезультатом работы этой функции.

При этом мало того, что функцию все равно придется вызывать (в продуктивном коде)

так еще у тебя и Request'e добавится куча полей.

Смотри свой собственный код, у тебя у Account есть как минимум две функции: hasSameOwnerAs и canWithdraw

Ясен хрен, что тут должна быть абстракция.

Т.е. Request - это тоже нифига не plain data объект!

Это должен быть интерфейс типа

ingle Responsibility Principle ничего не говорит о том, что в классе должна быть одна функция.

может мне ещё и JDK мокать? java.lang.Math.sin, например?

А то ж вдруг я его вызываю, да синус считаю. Ты сам-то мокаешь стандартную библиотеку?

Также как и любое другое поле: передам нужное мне значение в конструктор

С хера ли? Ты что, Егора Бугаенко начитался/насмотрелся? Plain data там, никаких объектов, никаких абстракций.

1) у каждой функции своя область определения, значит у каждой будет свой Request

2) нафига перегружать модуль Transfer ещё десятком какимх-то функций? Про Single Responsibility Principle слышал?

Затем, что ты этот метод вызываешь и действуешь исходя из возвращаемого этим методом значения.

Это поле надо будет как-то заполнить. Как ты собираешься это сделать?

(которые на секундочку должны быть полноценными объектами, а еще точнее абстракциями)

Если у тебя в классе Transfer будет 10 функций (submit, rollback, list, rejeckt, еще что-то) и все они будут что-то рассчитывать опираять на данные из source и/или destination, то тебе придется добавлять 10 функций твой Request.

А еще Account и Money чтобы работа шла так, как было задумано, а не по умолчанию

ФП и декларативное программирование ортогональные вещи на самом деле.

Если ты про canWithdraw, то это простой чистый метод, зачем его мокать?

Но можно canWithdraw вынести в Request как Lazy<Boolean>-поле, и снова мокать ничего не надо.

Я их сделал явными и ограниченными.

Не надо, мне нужно знать только тип входных данных (Request) и тип выходных данных (Response), которые полностью описывают всё, что нужно.

вместо того, чтобы декомпозировать код и вынести логику retry в отдельный RetriableConnection с настраиваемой политикой, отдельно и независимо протестированную, Fester решил накостылять сомнительные тесты прям над бизнес-логикой, сохранив её сложность и зафиксировав эту сложность в спецификации (тесте).

в мире ФП у меня остался и покрашенный и непокрашенный

Не применима, т.к. позволяет менять уже существующие причинно-следственные события,

когда в реальном мире они не меняются, только порождаются новые. Чисто. Функционально.

Наличие дополнительного ручного тестирования никак не отменяет необходимость автоматических тестов на разных уровнях.
А TDD - это вообще про написание кода больше

но в подавляющем большинстве не критических для жизни людей проектов все именно так.

Как видишь Request придется тебе мокать целиком и полностью...

Как видим, ни от каких зависимостей ты не ушел

а реализацию тебе надо знать чтобы не мокать то, что не нужно в данном тесте.

Ага, пользуясь тем, что аргументы функции вычисляются гарантированно раньше самой функции.

Даже вон do-нотацию придумали, чтобы упростить маскировку.

Наш мир, в первую очередь, причинно-следственный, и поэтому императивная модель

Невозможно сварить борщ не составив последовательность действий. Даже если ты просто собираешь домик из готовых кубиков, ты не можешь начать строительство с крыши.

Ну есть скажем требование: "в случае неудачного соединения N-раз повторить повторить попытку, после чего сообщить пользователю об ощибке". Вполне себе нормальный сценарий, который тоже можно протестировать.

Нет, наши физические компьютеры имеют императивную модель, а мир чисто конкурентно-событийный.

Не надо мне мокать Request, я же написал пример теста, где там мок?

А это ещё одна проблема с моками: их любители часто думают, что пишут юнит-тест, но фактически получают интеграционный =)

Никто не мешает тебе изменить контракт на

Теперь тебе надо мокать Request и точно также мокать 2 аккаунта

Это если речь идет о интеграционном тесте, он же пишет юнит тест.

Да ни фига, просто маскируют императивность монадами да хвостовыми рекурсиями.

Так уж сложилось, что наш физический мир императивен

Т.е. наличие параметра Accounts в публичном конструкторе — это часть контракта, публичная внешняя зависимость, а как именно используется экземпляр Accounts — это деталь реализации и «знание» этой детали в тесте — прямое нарушение инкапсуляции.

Ни одной внешней зависимости с полным сохранением функциональности.

Вводится дополнительный класс с дополнительной логикой.

Сравни:

И если в варианте с моком тестировать надо только одну функцию, то в предлагаемом тобой подходе тестировать надо 3 функции.

Просто в реальном мире данные надо брать из многих разных источноков, сопоставлать эти данные и принимать какое-либо решение.

Именно для этого и нужны моки
В примере выше тест для суммы выглядел бы так:

По мне так декларативный код - утопия.

Ну, скажем, у тебя из-за (слишком) ленивых вычислений в программе на haskell появляются моменты, когда память то почти свободна, то лавинообразно забивается и все начинает тупить.
Соответственно, можно чуть иначе попытаться написать код и расход память станет стабильнее.

С чего вдруг сложной? В чем заключается сложность? Я не понимаю.

Если у тебя функция и жнец и жрец и на дуде игрец, тогда это явно говорит о плохом дизайне в твоем приложении и о жестких зависимостях, от которых нужно избавляться.

Тестируемая функция в ЮТ не должна не от чего зависеть, она должна быть автономной. Т.е. если у тебя в каком то 1 методе ошибка. То в юнит тестах - должен быть сфейлен ровно 1 UT из 1000 запущенных, даже если в программе у тебя куча мест, которые используют эту функцию/метод.

Всё было плохо.

Если у тебя новые требование (новая формула, скажем, умножать нужно не на два, а на три), то естественно нужно написать новую функцию и использовать там, где нужно, а не трогать старую. Ты что, open-close принцип забыл?

А что такое «оптимизация декларативного кода»?

А хорошо получалось или было все нестабильно?

А, то есть мы полностью переписываем код каждый раз?

То, что если он недекларативен ради оптимизации, то тогда тесты имеет смысл писать?

А что, декларативный код не оптимизируют?

Прикол в том, что 3-й класс делает систему неоправданно сложной.

Весь прикол заключает в том, что если пользоваться терминологией автора этой статьи (т.е. UT не имеет мок-объектов, а то, что имеет мок-объекты - это интергационные тесты), то не существует систем, которые тестируются юнит-тестами

Юнит-тестами можно протестировать только базовые компоненты, а продуктивный (aka полезный) код тестируется исключительно интеграционными тестами.

Например, у нас есть модуль, который контролирует передачу RFID чипов. Каждый евент от RFID-антенны сохраняется в БД и передается от 0 до n раз на 5 других подсистем. И вся информация о правильном поведении идет из вне Ну и каких "юнит-тестах" (в понимании автора статьи) тут можно говорить?

Соответственно первый класс для вычисления суммы, второй для логирования, а третий агрегирует в себе эти два.

Вот автор и описывает - что такой подход ведет к запутанности, сильной зависимости, и соответственно к подводным камням и ошибкам.

Видел я как такой стартап использует эти практики. Ничем от херак-херак не отличается.

Э нет, делать фичу — это новые требования и новая реализация.

Про оптимизации я уже писал.

Как раз обычно все эти быстрые стартапы часто активно используют эти "новые" хорошие инженерные практики

Программисты такие, знаешь ли. Код правят. Делали фичу, рефакторили, оптимизировали - выбирай на свой вкус.

А так все верно, да. Просто я бы предложил перед интеграционными тестами, делать еще ЮТ с моками, чтобы некоторые ошибки отлавливать раньше запуска интеграционных тестов.

Вот если вместо "говорит о том, что модули сильно взаимосвязаны" написать "может говорить о том, что модули сильно взаимосвязаны", то я соглашусь

What is a code smell?
“A code smell is a surface indication that usually corresponds to a deeper problem in the system.” ~ Martin Fowler
A code smell does not mean that something is definitely wrong, or that something must be fixed right away. It is a rule of thumb that should alert you to a possible opportunity to improve something.
This text and its title in no way imply that all mocking is bad, or that you should never mock anything.
Additionally, different types of code need different levels (and different kinds) of mocks. Some code exists primarily to facilitate I/O, in which case, there is little to do other than test I/O, and reducing mocks might mean your unit test coverage would be close to 0.
If there is no logic in your code (just pipes and pure compositions), 0% unit test coverage might be acceptable, assuming your integration or functional test coverage is close to 100%. However, if there is logic (conditional expressions, assignments to variables, explicit function calls to units, etc…), you probably do need unit test coverage, and there may be opportunities to simplify your code and reduce mocking requirements.
---
What is tight coupling?
The need to mock in order to achieve unit isolation for the purpose of unit tests is caused by coupling between units. Tight coupling makes code more rigid and brittle: more likely to break when changes are required. In general, less coupling is desirable for its own sake because it makes code easier to extend and maintain. The fact that it also makes testing easier by eliminating the need for mocks is just icing on the cake.
From this we can deduce that if we’re mocking something, there may be an opportunity to make our code more flexible by reducing the coupling between units. Once that’s done, you won’t need the mocks anymore.
Coupling is the degree to which a unit of code (module, function, class, etc…) depends upon other units of code. Tight coupling, or a high degree of coupling, refers to how likely a unit is to break when changes are made to its dependencies. In other words, the tighter the coupling, the harder it is to maintain or extend the application. Loose coupling reduces the complexity of fixing bugs and adapting the application to new use-cases.
---
What does composition have to do with mocking?
Everything. The essence of all software development is the process of breaking a large problem down into smaller, independent pieces (decomposition) and composing the solutions together to form an application that solves the large problem (composition).
Mocking is required when our decomposition strategy has failed.
Mocking is required when the units used to break the large problem down into smaller parts depend on each other. Put another way, mocking is required when our supposed atomic units of composition are not really atomic, and our decomposition strategy has failed to decompose the larger problem into smaller, independent problems.
When decomposition succeeds, it’s possible to use a generic composition utility to compose the pieces back together. Examples:
---
When you use generic composition utilities, each element of the composition can be unit tested in isolation without mocking the others.
The compositions themselves will be declarative, so they’ll contain zero unit-testable logic (presumably the composition utility is a third party library with its own unit tests).
Under those circumstances, there’s nothing meaningful to unit test. You need integration tests, instead.

Ну и автор не говорит что нельзя моки юзать в ЮТ и все тут, он как бы намекает, что если в ЮТ используются Моки то это уже говорит о том, что модули сильно взаимосвязаны, и можно переписать куда лучше, чтоб избавится от моков.

Ну т.е. все сводится к тому какой тест можно назвать юнит-тестом, а какой уже интеграционный. Вопрос не в сути, а в терминологии. При этом ради сохранения чистоты терминологии автор готов пойти на усложнение кода и, соответственно, добавление ошибок.

И не просто так придется вводить интерфейс. Т.к. у тебя будет
Calculator : ICalculator
CalculatorWithLogger : ICalculator
CalculatorWithDatabase : ICalculator
CalculatorWithLoggarAndDatabase : ICalculator
что, как ты понимаешь, легко может привести к ошибке.

Для исключения ошибки тебе придется вводить еще один интерфейс:
Calculator : ICalculatorUnit
CalculatorWithLogger : ICalculator
CalculatorWithDatabase : ICalculator
CalculatorWithLoggarAndDatabase : ICalculator

которая конвертирует температуру по Кельвину в температуру по Цельсию

Так я выше написал, что этот класс будет тестироваться с помощью интеграционных тестов.

Если у тебя будет как ты выше написал CalculatorWithLogger, CalculatorWithDatabase, CalculatorWithLoggarAndDatabase, то тут в любом случае придется вводить интерфейс. Ты уже докапываешься до незначительных деталей ИМХО.

Какая эта функция?

Да, вот только функция уровнем выше (которая будет использовать CalculatorWithLogger) ничего не должна знать про существование CalculatorWithLogger, ей известен только ICalculator... Т.е. либо тебе придется вводить еще одну абстракцию, либо ты рискуешь совершить ошибку передав в CalculatorWithLogger в качестве ICalculator другой CalculatorWithLogger.

Проблема в том, что эта функция должна либо сама создать объект CalculatorWithLogger (для этого ей надо будет как-то получить ILogger и ICalculator), либо функция должна будет получить CalculatorWithLogger в качестве параметра (это насколько я понимаю, противоречит требованию к юнит-тесту)

А если пойти еще дальше и к логгеру добавить... ну скажем запись в БД, при этом и запись в БД и логгер опциональны, то у тебя получается такой вот зоопарк: Calculator, Logger, Database, CalculatorWithLogger, CalculatorWithDatabase, CalculatorWithLoggarAndDatabase.

Согласись, решение так себе...

Либо создай класс LoggerCalculator, в котором например ты можешь логировать и считать сумму.
Например на основе нашего кода выше:

Почему не удовлетворяет? Удовлетворяет. Все действия запротоколированны. Посмотри код выше. Юзать то ты будешь CalculatorWithLogger.

Отличное решение!
Пусть нас надо написать функцию, которая конвертирует температуру по Кельвину в температуру по Цельсию. Протестированный калькулятор у нас уже есть. Давай использовать его Не забываем, что каждый вызов калькулятора должен быть запротоколирован логгером. Как должна выглядеть такая функция и тест к ней?

Логировать ты можешь в другом месте, например на уровне выше.

Еще раз. Так может быть. И поэтому действительно к мокам нужно осторожно относиться. Но вот представь, что мы все пишем так, как рекомендуется в статье, а потом, дополнительно, еще пишем ЮТ, где мокируем всякий ввод/вывод, работу с базой, сеть и пр. То есть делаем дополнительные проверки перед интеграционнымм, чтобы раньше узнать о проблемах. Я не понимаю, почему это плохо.

Интеррационный тест для того и нужен, чтобы проверить взаимодействие двух реальных объектов. Т.е. суть интергационного теста - как раз отсутсвие мока.

When you use generic composition utilities, each element of the composition can be unit tested in isolation without mocking the others.
The compositions themselves will be declarative, so they’ll contain zero unit-testable logic (presumably the composition utility is a third party library with its own unit tests).
Under those circumstances, there’s nothing meaningful to unit test. You need integration tests, instead.

Ну вот представим, что у тебя есть 2 компоненты: калькулятор и логгер. Все действия калькулятора должны быть запротоколированы. Как должен выглядить идеальный юнит-тест суммы?

Логировать ты можешь в другом месте, например на уровне выше.

That means that the code you use to set up network requests and request handlers won’t need unit tests. Use integration tests for those, instead.

That bears repeating:
Don’t unit test I/O.
I/O is for integrations. Use integration tests, instead.


It’s perfectly OK to mock and fake for integration tests.

А если они в ЮТ - то у тебя слабо декомпозирована система, и есть жесткие связи, без которых ты не можешь протестить функционал, что является кладезью ошибок.

А если они в ЮТ - то у тебя слабо декомпозирована система, и есть жесткие связи, без которых ты не можешь протестить функционал, что является кладезью ошибок.

Ну так моки и помогают протестить в юнитах то, что без них можно будет тестить только в интеграционных тестах. Конечно, их не должно быть много. Но в абсолют я бы это не возводил.

Самая ранняя из возможных — это хинты IDE от компилятора и анализатора.

Что он показывает, так проблемы анализа и постановки задач и вместо нормального решения затыкает костылём (собой).

…никогда не дойдёшь до реализации. Либо вместо тебя дойдут конкуренты по методу херак-херак и в продакшн, но это уже другая история.

Не помогло. Добавило новых.

Контракт этого кода: сумма удвоенных нечётных целых чисел из списка. Именно это в нём и написано. Дальше что?

Зачем вы поправили код?

Это ещё с какого хера? Если у этих мест появились новые требования (новый контракт), пусть сами его использование и чинят. Моя задача, как реализатора контракта — реализовать его.

Что ж, удачи тебе. )

Основная идея в том, что если у тебя есть Моки, значит у тебя тесная связь, и твоя функция/система зависит от чего то извне, без чего не может быть протестирована, а это типа херово. ... Типа моки нужно применять в интеграционных тестах, и весь функционал, которые не покрывают UT - подразумевается что он должен работать с IO, соккеты/файлы/чета там еще, поэтому это тистируется интеграционными тестами. Ну это как я понял из статьи выше.

Надо писать код в функциональной парадигме, чтоб этого избегать, чистые функции(без сайд эффектов), всякие там монады(then().then().then...) и т.п.

Ironically, most of the sources of coupling are mechanisms originally designed to reduce coupling. That makes sense, because in order to recompose our smaller problem solutions into a complete application, they need to integrate and communicate somehow. There are good ways, and bad ways. The sources that cause tight coupling should be avoided whenever it’s practical to do so. The loose coupling options are generally desirable in a healthy application.
You might be confused that I classified dependency injection containers and dependency injection parameters in the “tight coupling” group, when so many books and blog post categorize them as “loose coupling”. Coupling is not binary. It’s a gradient scale. That means that any grouping is going to be somewhat subjective and arbitrary.
I draw the line with a simple, objective litmus test:
Can the unit be tested without mocking dependencies? If it can’t, it’s tightly coupled to the mocked dependencies.
The more dependencies your unit has, the more likely it is that there may be problematic coupling. Now that we understand how coupling happens, what can we do about it?