Привет!

Я начал писать третий вариант сериии/поста о солид:)

Поэтому снова ссылка:) Когда использовать моки, по версии анкл Боба
Суть:
1) Только на границах системы - внешние системы, СУБД. веб-сервер. И я даже тут не согласен -
1.1) интеграцию приложения с веб-сервером, я проверяю интеграционными тестами (которые работают по HTTP) и тут мокам сервера я не верю,
1.2) лоигку работы приложения я проверяю через "сервисы" - и тут сервер уже вообще не нужен.
2) СУБД я запускаю в контейнере на каждый запуск тестов. Это даёт константную прибавку ко времени тестов в 5-10 секунд. А потом я уже не вижу разницы во времени работы. Я даже как-то баловался с тем, чтобы контейнер завести на RAM-диске - у меня разницы не было, но с HDD, наверное на этот стоит заморочиться
3) Вобщем я только мокаю внешние системы (https://azhidkov.pro/posts/21/03/210321-project-l-testing/)

#posts@ergonomic_code #whynomocks@ergonomic_code

Привет!

Выжимка из выжимки о тестировании:)

1) избегайте моков любой ценой. в оригинале - "используйте их только на границах модулей". Моя версия - используйте их только для систем вне вашего контроля (внешине сервисы)
2) Избегайте деталей реализации, тестируйте поведение - изменение состояние заметное внешнему наблюдателю
3) Триггером нового теста является не новый метод или класс, а новое требование. Или старый баг - прим. пер.
4) Пишите тесты, которые проверяют юз кейсы или юзер стори
5) изолировать надо не тестирумый класс, от остального кода, а сами тесты друг от друга

Там есть ещё пара пунктов о том, что надо мокать БД и дёргать код напрямую, а не через HTTP. Но тут я не согласен - такие тесты лично мне не дают уверености, что всё работает

#posts@ergonomic_code #whynomocks@ergonomic_code #ergo_testing@ergonomic_code

Привет!

Давным давно - практически до нашей эры по меркам ИТ - в 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

Привет!

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

Мысль №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

Привет!

Опубликовал пост с последним кусочком описания сетапа фикстуры Trainer Advisor - сетап тестовых дублей.

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

И под это дело добавил соответствующий бонус-трек в пост с описанием запуска инфраструктуры.

#trainer_advisor@ergonomic_code #ergo_testing@ergonomic_code #whynomocks@ergonomic_code

Привет!

Мне тут на Хабре заминусили коммент про отказ от моков в пользу интеграционного тестирования.
В ответ на это я собрался мокистам ответить подборкой цитат классиков и экспертов по ТДД о моках и оказалось, что у меня её нет.

Теперь есть:)

Берите себе на вооружение, в своей борьбе за простое девелоперское счастье и здоровый ночной сон:)

#posts@ergonomic_code #whynomocks@ergonomic_code #ergo_testing@ergonomic_code