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

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

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

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

а в реальном декларативном коде не вознкает потребности в рефакторинге?

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

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

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

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

Можно попробовать приложить ум к символическим ссылкам. Подсчёт занимаемого объёма учитывает контент по ссылкам, и это в неком смысле правильно, тогда как при перемещении на новое место будут перемещены ссылки, а не сами объекты, и это тоже в неком смысле правильно.

Логгинг в этом плане идеальный пример, т.к. логгером можно отслеживать процесс. Согласись, далеко не все функии умещаются в одну строку. И логгинг бывает разного уровня (debug, info, warn, error, fatal итд).

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

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

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

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

Но у тебя в ТЗ оговорено что класс должен и логировать и вычислять сумму.

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

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

Зачем ты начал рефакторить то, что и так ясно отражает суть?
Про оптимизацию я уже писал, но ты всё пропустил.

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

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

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

Простой пример. Начал рефакторить или оптимизировать, ошибся в чем-то. Сломал.

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

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

А вот такие, как "удалил с диска 37 гигов, а свободного места стало 1 гигов" - во, такие чудеся сплошь и рядом... :wall:
И это не фокусы, а реальность...ума не приложу, как это может быть...

Мне эту всю лабуду вручную править в планировщике? Свят-свят.

Я может плаваю в теории, но в интеграционных тестах вместо моков уже должны быть реальные объекты, разве нет?

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

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

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.

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

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

Принцип единственной ответственности не запрещает DI и не запрещает общаться с другими компонентами.

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

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

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

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

Конечно, и что в этом плохого? Есть такой принцип: Принцип единственной ответственности буква S, из абрревиатуры SOLID, вот мы как раз ему и последовали. В чем косяк то?

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

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

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

Кстати, даже в этом коде есть логика, которую можно тестировать
Либо ты должен проверять параметры конструктора и кидать исключение в случае если logger или calculator имеют нулевые значения. Либо ты должен проверять на ноль непосредственно при сложении. Т.е. тут цикломатическая сложность гарантированно больше 1, а значит надо делать тест. Можно конечно назвать этот тест интеграционным, но мне кажется, что это уже дрочерство на терминологию

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

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

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

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

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

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