Привет!

Давным давно - практически до нашей эры по меркам ИТ - в 2014 году, David Heinemeier Hansson (автор Ruby on Rails) устроил бучу под названием "TDD is dead". Эта буча дошла до одного из отцов-основателей TDD - Кента Бека и они на троих с Мартином Фаулером устроили публичные дебаты на эту тему - рекомендую послушать, там много полезного о тестировании.

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

И вот вырезка о том, что сам Кент практически не использует моки:
My personal practices... I'm mock almost nothing. If I can't figure out how to test effciently with the real stuff I find another way of creating a feedbacj 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.

TW Hangouts | Is TDD dead?

#talks@ergonomic_code #tdd@ergonomic_code #ergo_testing@ergonomic_code #whynomocks@ergonomic_code

Привет!

Нашёл железобетонный аргумент в пользу классической школы тестирования:)

> You may have heard of famous Classicist TDD practitioners including Uncle Bob and Kent Beck. If you want an example of a Mockist look no further than Sandi Metz, J.B Rainsberger or Steve Freeman
Test Driven Development Wars: Detroit vs London, Classicist vs Mockist

Так, ну анкл Боба и Бека каждая собака знает. Если что, Фаулер - тоже классицист.

А вот за эти ваши моки - что за господа (и дамы) с горы топят? Они даже в выдаче стартпейджа ниже футболистов. Единственное известное (мне) творение этих авторов - Growing Object-Oriented Software, Guided by Tests - Хориков (тоже классицист) в части дизайна и качества тестов разнёс в пух и прах.

А если серьёзно, я начинаю потихоньку отходить от абсолюта "не используйте моки никогда!" - так что не сильно удивляйтесь, увидев пост "Когда и как стоит использовать моки?":) Тизер: тогда, когда надо симулировать ошибку, отгородится от дорогой/медленной/нестабильной внешней системы и стараться мокать только стабильные интерфейсы.

#posts@ergonomic_code #ergo_testing@ergonomic_code #tdd@ergonomic_code #whynomock@ergonomic_code

Привет!

Вчера в Проекте Э пришлось подравить пару МРов своими собственными руками (редкое событие в последнее время, к сожалению), чтобы успеть заталкать в релиз.

И в обоих случаях ТДД спасло меня от внесения багов.

В первом случае мне надо было замапить ошибку нарушения уникальности констрейнта с 500 на доменно-специфичную. Я как и положено начал с теста, починил, увидел зелёный тест и пошёл рефакторить. И сломал. Благо тест отловил.

Во втором случае, я в оригинальном МРе убрал часть логики (обновление времени действия пользователя в одном из кейсов). А потом выяснилось что всё-таки обновлять время надо. На этот кейс теста не было, поэтому я опять же начал с него. Вернул оригинальный код и. Тест не прошёл. Там был баг. Который я благополучно починил.

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

#project_e@ergonomic_code #tdd@ergonomic_code #ergo_testing@ergonomic_code

Привет!

У меня для вас снова поучительная история про тесты.

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

А тут поменяли и ой.

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

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

Подтягиваю, мастер в ветку где это надо - а она не собирается О_О Тест не проходит. Потому что данные поменялись. А я продовый код не вернул перед коммитом 🤦‍♂️

Мораль этой басни - очень важно видеть как тест превращается из красного в зелёный.
Самый рациональный и надёжный способ это делать - писать сначала тесты.
Если вы пишите сначала продовый код - надо хотя бы ломать его после тестов, и убеждаться что они красные, а потом становятся зелёными.
Ну а если вы написали продовый код, написали тесты, они сразу прошли и вы на этом остановились - ну чтож, удачи в проде:)

#case@ergonomic_code #ergo_testing@ergonomic_code #tdd@ergonomic_code

Привет!

Второй или третий раз смотрю де-факто один и тот же доклад про ТДД и не устаю его рекомендовать - в этот раз по мотивам доклада у меня снова родилась пачка мыслей.

Мысль №1
В докладе мужик привёл пару определений:
> Падение юнит-теста подразумевает сбой ровно в одном юните (методе, классе, модуле, пакете)
> Падение девелоперского теста подразумевает ошибку в последнем изменении кода

И мысль ещё из Бековской TDD by Example - кол-во кода, которое вы пишите между запусками тестов зависит от вашей уверенности в умении писать такой код.
И аналогия с вождением машины - чем увереннее вы себя чувствуете, тем быстрее вы едете.

И это прям хорошо легло на мой свежий опыт:
1. В Trainer Advisor у меня примерно 3-4 теста на HTTP-эндпоинт. И ~95% - работают либо через хттп, либо через конторллер
2. А недавно я написал один хттп эндпоинт, с 22 тестами из которых <50% работают через http.

В чём разница? В TA львиная доля эндпоинтов - примитивный КРУД - перегнать ДТО в сущность, сохранить сущность; вычитать ДТО из БД, вернуть - я это пишу спинным мозгом и там граничных случаев ноль целых хрен десятых.

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

В этом и разница.

—

Мысль №2
Что переход на более низкий уровень абстракции, что использование мока - снижают устойчивость тестов к рефакторингу и, как следствие, увеличивают стоимость разработки (читай: вашу нервотрёпку). Но, при этом снижают стоимость разработки самих тестов. И надо стараться искать оптимальное соотношение разных типов тестов, которое обеспечит минимальную стоимость разработки (читай: вашей нервотрёпки). Пока могу предложить это только в качестве лозунга - как конкретно искать этот баланс я не знаю.

—

Мысль №3
Возможно молодые подписчики ещё не сталкивались с http://wiki.c2.com/. Это самая первая вики в мире из 1995 года. От чувака, который придумал гексагональную архитектуру. И в которой в старые добрые времена тусила вся старая гвардия - начиная с самого Кокберна и продолжая анкл Бобом, Фаулером, Беком, Коплейном. Можно выделить вечерок и пошататься по ней впитывая мудрость древних.

—

Мысль №4
Чёт то ли я туплю, то ли у мужика не стыковка - он сначала пинает тесты с моками, за то что они мешают рефакторингу. А в конце доклада предлагает писать тесты на код интеграций с моками. Чтобы их потом не рефакторить?

—

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

—

Мысль №6
У мужика в докладе ни строчки кода нет. А у меня есть ~150 "developer tests", которые "tests behaviour, not functions" и для которых процентов на 30 готово описание идей и техник как, такие тесты писать

#talks@ergonomic_code #ergo_testing@ergonomic_code #tdd@ergonomic_code #whynomocks@ergonomic_code

Привет!

Не прошло и месяца и я сделал это!

Представляю вашему вниманию Project Mariotte - минималистичный и подробно задокументированный демопроект Эргономичного подхода на примере сервиса бронирования номеров в отелях.

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

#project_mariotte@ergonomic_code #ergo_approach@ergonomic_code #spring@ergonomic_code #tdd@ergonomic_code #functional_architecture@ergonomic_code #dop@ergonomic_code #immutable_domain_model@ergonomic_code

Привет!

Я в Project Mariotte сделал страшное - перешёл на MockMvc.

Изначальная мотивация была в том, чтобы сэкономить секунду на запуске Tomcat.

Потом выяснилось, что инициализация RestAssured занимает ещё секунду, которую тоже можно сэкономить

Но последним аргументом стало то, что со WebTestClient можно переехать на работу через HTTP за три четыре простых шага.

И это навело меня на мысли об эволюции ЭП от сложного к простому за последние 4 года.

В конце 19-ого - начале 20-ого года можно было сказать, что ЭП = модульный монолит + тесты без моков + ДДД + чистая архитектура + railway-oriented programming на монадах.

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

Но за прошедшие 4 года, они все если не вошли, то сильно приблизились к мейнстриму, на мой взгляд.

А я с ЭП за эти же 4 года то ли ушёл вперёд, то ли откатился назад:

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

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

3. От ДДД осталась только декомпозиция модели на агрегаты, но по более приземлённой технологии на базе жизненного цикла сущностей и транзакционного анализа; а вместо ограниченных контекстов - декомпозиция на базе эффектов;

4. Чистую архитектуру я заменил на тщательное проектирование интерфейсов;

5. ROP на монадах, наконец, я заменил на Guard clause.

И при этом Эргономичный подход остаётся совместимым со всеми этими идеями там, где это надо:

1. Цитадель оказалась плохой затеей? Затолкать её обратно в монолит - вообще не проблема;

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

3. В проекте появилась сложная предметная область и/или эксперт по ней? Перейти на ограниченные контексты и агрегаты на базе инвариантов - без проблем, вся инфраструктура и структура кодовой базы готовы;

4. В проекте появилась необходимость менять инфраструктуру без пересборки/перезапуска? Вытащить интерфейс из существующего класса - дело 5 минут. С реализацией сложнее, но это другой вопрос;

5. В проекте появилась потребность на лету собирать пайплайны? Обернуть имеющиеся вызовы эффективных методов в монады не составит труда.

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

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

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

В общем, покой нам только снится:)

#ergo_approach@ergonomic_code #project_mariotte@ergonomic_code #tdd@ergonomic_code #ergo_testing@ergonomic_code #mocks@ergonomic_code #clean_architecture@ergonomic_code #functional_architecture@ergonomic_code #ddd@ergonomic_code #rop@ergonomic_code

После Project Mariotte я перенёс подход с MockMVC на другой (закрытый) проект и словил там проблему - по дефолту настройки секьюрити не подтянутся.

Для того чтобы их прикрутить надо:
1. Не забыть добавить зависимость testImplementation("org.springframework.security:spring-security-test")
2. Донастроить webTestClient:

         client = MockMvcWebTestClient
            .bindToApplicationContext(applicationContext)
            .apply(springSecurity(FilterChainProxy(securityFilterChain)))
            .configureClient()
            .defaultHeader("Content-Type", "application/json")
            .build()

Возможно там где-то дальше ещё какие-то грабли есть, но меня утешает мысль, что вернуться к тестам через HTTP можно будет лёгким движением руки

#ergo_testing@ergonomic_code #tdd@ergonomic_code #mockmvc@ergonomic_code #springsecurity@ergonomic_code #webtestclient@ergonomic_code

Привет!

Я как всегда облажался с оценкой оверхеда на сетап проекта и сроки по Проекту Р начали подгорать.
Поэтому на этой недели не расскажу, как поднимаю БД на 300+ таблиц, собираемых из 8 лет миграций меньше чем за пару секунд.

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

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

spring:
  datasource:
    url: "jdbc:tc:postgresql:16.3:///bender?TC_REUSABLE=true&TC_TMPFS=/var:rw"

#tdd@ergonomic_code #integration_tests@ergonomic_code #project_r@ergonomic_code

Привет!

Сроки по Проекту Р уже полыхают синим пламенем но я, тем не менее, повыкраивал по чуть-чуть времени на микропост с описанием того, как я добился сетапа свежей БД на 300+ таблиц за 1.5 секунды.

#ergo_testing@ergonomic_code #tdd@ergonomic_code #integration_tests@ergonomic_code #project_r@ergonomic_code

Ну и собственно очередной досмотренный видос - Test automation without a headache: Five key patterns.

Мне понравился, рекомендую.

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

2. Симулируйте только те штуки, которые вы полностью понимаете. Это классика из Growing Object-Oriented Software, что мокать можно только собственные классы.

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

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

5. Реорганизуйте тесты для discovery. Посыл вроде как "организуйте тесты не воркуг юзер стори/итераций, а вокруг функциональности". Но лично я ни разу не видел первый вариант.

Есть ещё версия на ютубе с субтитрами и короче на 25 минут

#talks@ergonomic_code #tdd@ergonomic_code

Привет!

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

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

#tdd@ergo_approach #case@ergo_approach

Что ещё почитать на тему тестирования
Принципы юнит тестирования - самая крутая книга на эту тему
TDD Revisited - Ian Cooper - NDC Porto 2023 - суть здорового тестирования за час пятнадцать
Пачка постов у меня про тестирование Trainer Advisor
Подборки постов у меня в канале - #tdd #nomocks

#ergo_testing@ergonomic_code #books@ergonomic_code #talks@ergonomic_code #posts@ergonomic_code