но мне хватает того факта, что если я написал тест на кейс Х, то он точно не стрельнет на проде. Значит меня не будут теребонькать на выходных.

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

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

Просто начните писать.

Не всё так просто. Начать писать - необходимое, конечно, но недостаточное условие.

Чтобы получить

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

важно, чтобы вся команда писала тесты. И писала качественные тесты, а не отписки для лида, лишь бы отвалил.

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

2. Result плохо интегрируется с библиотеками. В частности Spring не откатит транзакцию, а корутины не закенсалят скоуп при возврате резалта. Транзакции точно, а коррутины скорее всего можно обработать напильником, но, опять же, через чур гемморойно, имхо

3. В Котлине нет нормальной возможности в верхнеуровневом методе вернуть пару разных ошибок из вызываемых методов и в итоге ошибка очень быстро превращается в Exception (корневой тип ошибок), чья информативность стремится к 0. Хотя это может решиться благодаря Rich errors (доклад с их представлением).

В итоге я разделил ошибки на восстановимые (которых в моих проектах очень мало) и не восстановимые. Восстановимые возвращаю резалтом и тут же обрабатываю, а не восстановимые бросаю исключениями которые улетают до контроллера (спецефичные для метода) или миддлваря (универсальные в духе resource-not-found). Всё это у меня подробно описано тут

Я обычно перед тем как писать какой-то код, проектирую и согласовываю АПИ с фронтом. И тесты пишу через это АПИ. А если там будут существенные изменения, то модификация тестов - будет меньшей из проблем:)

Пока набралось два кейса:

1. Сравнение трудозатрат на первоначальную разработку и её полный реинжиниринг

2. Субъективное ощущение продакта на разработку большой фичи (человеко-год) по ТДД в сравнении с другими фичами в том же проекте. Тут ретру пока не публиковал

И в обоих кейсах разработка по ТДД была не медленнее разработки без тестов и команда допуска в 2-4 раза меньше багов.

Ну то есть с ТДД можно шипать фичи с той же скоростью, но при этом спокойно спать и в целом меньше стрессовать:)

Только я бы добавил про

Изолируйте все внешние зависимости

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

У меня последние лет 5 в куче разных проектов (среди прочих - автоматизация выделенного бизнес-процесса крупного ритейлера, медтех, автоматизация работы юридического департамента) 90% "причины по которой я пишу ПО" - положить данные в РСУБД. И поэтому 90% кода тестировать в изоляции от внешнего мира особого смысла нет. В общем, на мой взгляд, изоляция внешних зависимостей - не универсальное правило и нужна только в сложных предметных областях (я таких не видел, но предполагаю, что к ним относится банкинг, страхование, логистика, e-commerce).

А в остальных случаях эффективнее по соотношению трудозатраты/(скорость + качество разработки), писать тесты как минимум с реальным PostgreSQL на RAM-диске.

И если заморочиться, такие тесты будут не критично медленнее - до 10 секунд на запуск 1 теста, и по 50мс в среднем на тест при запуске всего набора.

В остальном - всё плюсую.

Очень хорошая статья.

Спасибо:)

ак с точки зрения проверки типов работает, что вы в мапу списков помещаете не список, а единственное значение? Я вижу, что groupedRow: Map<String, List<Any?>> , но не понимаю, что такое делает + , что тип стал Map<String, Any>

List<Any?> - является подтипом Any.

"оператор" + - это на самом деле просто синтаксический сахар для создания копии мапы и добавления в неё элемента (копирование вместо добавления в имеющуюся - из-за ФП головного мозга)

Соответственно:

1. Метод groupBy возвращает Table aka List<Map<String, Any>>

2. Лямбда, которая передаётся в rowGroups.map возвращает Map<String, List<Any?>>

3. А сам метод map возвращает List<Map<String, List<Any?>>>

4. И при возврате из метода groupBy выполняется upcast (приведение к супертипу) List<Map<String, List<Any?>>> -> List<Map<String, Any>>

И как вы находите границы микросервисов и ограниченных контекстов?

Условно ко мне пришёл продакт, говорит хочу фичу логистики, она должна делать то-то и то-то - в результате какого процесса у меня появятся артефакты/термины "ПВЗ Customer", "ПВЗ Маппер" и т.д. и "Ограниченный контекст ПВЗ", "Ограниченный контекст Геоданные" и т.д.

Поясните, пожалуйста - куда и на каком уровне абстракции фронт встраивается в вашей модели?

В моей практике фронтовые приложения/компоненты зачастую работают со множеством (всеми) слабосвязанных между собой компонентов бэка и, кажется, сломают всю стройную картину - если фронт засунуть в один из ограниченных контекстов - он его coupling убьёт, а если в отдельный - у него самого ещё хуже coupling будет.

Я пишу, что отношение тестов без моков к тестам с моками может быть 100 к 1. То есть без моков никак - бывает в одном случае из ста. В моей практике последних 4 лет - 9 коммерческих проектов суммарно на ~100К строк Котлин-кода.

При этом среднее время теста по моим проектам - порядка 50мс:

Тут ещё, пожалуй, стоит пояснить, что под "моками" я понимаю именно мокирование собственных типов с помощью условного Mockito. А против условных WireMock, GreenMail и т.п. я ничего не имею, включая верификацию вызовов - это часть наблюдаемого (снаружи) повдениия системы, которая должна быть специфицирована в тестах.

В моём предыдущем проекте с тестами без моков за 500 человеко-часов, которые я рассматривал в ретроспективе было 0.5 бага на задачу или 0.05 бага/человеко-час (подробности).

В текущем проекте за примерно человеко/год разработки нашли 2 бага (не соответствие поведения софта требованиям) и 0 регрессий. Проект ещё не завершён, поэтому ретру не проводил и точных цифр пока нет.

В этом же проекте с 93% покрытием кода тестами без моков я недавно сделал пару серьёзных изменений в модели и рефакторингов: сделал один из агрегатов частью другого, ввёл разделение доменной модели и модели персистанса, добавил версионирование частей агрегата (условно таблички и её строк) - в ходе этой работы не было внесено ни одной регрессии.

А рефакторинг (20 затронутых файлов файлов, 482 добавленных строки, 172 удалённых строки) не содержал ни одной строки изменений в тестах.
Это красноречивая иллюстрация того, что хорошие тесты проверяют поведение системы, а не её реализацию и, как следствие, не меняются при рефакторинге - изменении структуры кода, без изменения его поведения.

Оставлю здесь мудрость древних для будущих поколений:

My personal practices…​ I’m mock almost nothing. If I can’t figure out how to test efficiently with the real stuff I find another way of creating a feedback loop for myself…​ I just don’t go very far down the mock path. I look at a code where you have mocks returning mocks returning mocks and…​ my experience is if I have…​ If I use TDD I can refactor stuff and then I heard these stories people say well I use TDD and now I can’t refactor anything and I feel like I couldn’t understand that and then I started looking at their tests…​ Well if you have mocks returning mocks returning mocks your test is completely coupled to the implementation…​ not on the interface but the exact implementation of some object …​ three streets away …​ of course you can’t change anything without breaking a test. So that for me is too high a price to pay that’s not not a trade-off I’m willing to make.

---

Мои личные практики…​ Я почти ничего не мокаю. Если я не могу понять, как эффективно тестировать c реальными зависимостями, я нахожу другой способ создать для себя цикл обратной связи…​ Я просто не хожу далеко по пути мокирования. Я смотрю на код, в котором у вас есть моки, возвращающие моки, возвращающие моки, и…​ мой опыт показывает, что если у меня есть…​ Если я использую TDD, я могу рефакторить кода, а потом я слышу эти истории, когда люди говорили, что я использую TDD, а теперь я ничего не могу отрефакторить, и я не мог этого понять, пока не начал начал смотреть на их тесты…​ Ну, если у вас моки возвращают моки возвращающие моки, то ваш тест полностью связан с реализацией…​ не с интерфейсом, а с точной реализацией какого-либо объекта…​ в трех кварталах отсюда…​ конечно, вы ничего не сможете изменить, не сломав тест. Так что для меня это слишком высокая цена, на которую я не готов пойти ни в коем случае.

— Кент Бек, основатель движения TDD, автор JUnit
TW Hangouts | Is TDD dead?

Personally I’ve always been a old fashioned classic TDDer and thus far I don’t see any reason to change. I don’t see any compelling benefits for mockist TDD, and am concerned about the consequences of coupling tests to implementation.

This has particularly struck me when I’ve observed a mockist programmer. I really like the fact that while writing the test you focus on the result of the behavior, not how it’s done. A mockist is constantly thinking about how the SUT is going to be implemented in order to write the expectations. This feels really unnatural to me.

---

Лично я всегда был сторонником старомодного классического подхода и до сих пор не вижу причин меняться. Я не вижу никаких убедительных преимуществ для mockist TDD и обеспокоен последствиями привязки тестов к реализации.

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

— Мартин Фаулер, автор таких книг как "Рефакторинг" и "Шаблоны корпоративных приложений"
Mocks Aren’t Stubs

In short, however, I recommend that you mock sparingly. Find a way to test – design a way to test – your code so that it doesn’t require a mock. Reserve mocking for architecturally significant boundaries; and then be ruthless about it. Those are the important boundaries of your system and they need to be managed, not just for tests, but for everything.

And write your own mocks. Try to depend on mocking tools as little as possible. Or, if you decide to use a mocking tool, use it with a very light touch.

If you follow these heuristics you’ll find that your test suites run faster, are less fragile, have higher coverage, and that the designs of your applications are better.

---

Вкратце, я рекомендую вам использовать моки с осторожностью. Найдите способ тестирования – спроектируйте способ тестирования вашего кода, чтобы он не требовал моков. Оставьте моки для архитектурно значимых границ, и там безжалостно мокайте всё (дословный перевод: "и затем будьте безжалостны к нему"). Это важные границы вашей системы, и ими нужно управлять не только для тестов, но и для всего остального.

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

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

— Роберт Мартин, автор SOLID и Чистой архитектуры
When To Mock

private fun updateTable(updateTableRq: UpdateTableRq): Table? =
        transactionTemplate.execute {
            if (updateTableRq.correctionData.isNullOrEmpty()) {
                return@execute null
            }

            val correctedRows = updateTableRq.correctedRows()
            val rowsExternalIds = correctedRows.map { it.externalId }.toSet()
            val table = tablesService.findTableByExternalIds(rowsExternalIds)

            if (table == null) {
                return@execute null
            }

            if (correctedRows.size != table.rows.size) {
                throw TableRowNotFoundException()
            }

            val settings =  tablesSettingsRepo.findByDocumentId(table.outgoingDocument.id)
                                      ?: throw ResourceNotFoundException()

            val referenceExternalIds = correctedRows.collectReferenceFieldsValues(settings.fields)
            val referenceIds = referencesService.findReferenceMapByExternalIds(referenceExternalIds)

            val systemName = table.rows.first().externalId.systemName
            val parsedCorrections = correctedRows.associateBy(UpdatedRowRq::externalId) {
                it.parseFieldValues(systemName, settings.apiFieldsById, referenceIds)
            }

            tablesService.updateTable(table) {
                val rowCorrections = parsedCorrections[it.externalId.externalId]
                tableRowsFactory.updateRow(settings, it, rowCorrections)
            }
        }

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

Разделением ИО и логики я борюсь с этим:

Легенда:

• Синие блоки - оркестрация, блоки которые взывают более одного типа других блоков и имеют когнитивную сложность <= 4

• Красные блоки - ввод, блоки которые делают ввод и имеют когнитивную сложность <= 4

• Зелёные блоки - бизнес-логика, блоки, которые не вызывают ввод или вывод и имеют когнитивную сложность <= 15

• Жёлтые блоки - вывод, блоки, которые делают вывод и имеют когнитивную сложность <= 4

• Оранжевые блоки - месиво, блоки которые и делают ио (их сложно тестить и сложно понимать из-за необходимости учитывать перформанс, обработку ошибок и порядок выполнения) и имеют когнитивную сложность > 4 (их сложно читать и хочется тестить)

Или вот ещё не раскрашенный пример:

И в идеале я стремлюсь (и очень часто у меня получается) к такому:

Но вы правы, что не всегда всё так просто и красиво. Однако достичь вот такого - вполне реально и в "волосатых" случаях:

Эта картинка как раз ближе к IOSP/IODA, чем к ФА. Ну и да, оранжевый блок я подчищу в понедельник - этот кусок только-только дописали просрав дедлайн из-за недооценки "волосатости" задачи:)

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

А если вы приведёте пример с действительно сложной в моём пониманиии бизнес-логикой - мне скорее всего будет а) лень б) не хватать вводных, чтобы отрефакторить его и разделить логику и ио:)

Но! В моём окружающем мире люди называют многослойной архитектуру, в которой domain logic зависит от persistence layer (который может выглядеть интерфейсами Spring Data репозиториев). И от такой вариации многослойной архитектуры, ПФА отличается ещё и запретом на обращение к persistence layer из domain logic.

На самом деле, видимо, тут же кроется и ответ на ваш первый комментарий: если делать многослойную архитектуру так, как её делают вокруг меня - она ни от чего не спасает и проекты по ней быстро превращается в большой ком грязи. Тот же Project Daniel - там были даже отдельные Maven-модули application-services и domain-services. Но это не спасло проект от превращения в большой ком грязи.

А ваша многослойная архитектура с правилом "доменная логика, которая не связана с вводом-выводом" как таки и позволяет "уйти от жёсткости и хрупкости".

Верхний уровень логики (application logic) занимается оркестрацией. Он обращается как к доменной логике, которая не связана с вводом-выводом, так и к другой группе функционала, которая связана только с вводом-выводом.

Добавьте туда модель данных в виде неизменямых классов и это ровно то, что я называю "Промышленной функциональной архитектурой".

Почему я считаю, что незименямость важна я писал тут. А реальный кейс (но без кода, к сожалению) как "конфетка превращается в шпинат" - здесь