Взвешенное, сбалансированное мнение. Минус этой статьи в том, что спорить в комментариях не о чем :) Поэтому расскажу историю.
Года полтора назад мы с автором перевода (привет, Артур!), еще будучи коллегами, стали участниками одной интересной заварушки. Несколько лет мы в качестве аутсорсеров успешно сотрудничали с одной немецкой компанией, у которой был, помимо нас, и своей отдел разработки. Все было хорошо, пока в один прекрасный(?) момент немцы не упоролись по TDD. Причем жестко так, классически, догматично. Российская сторона не хотела принимать новые правила игры, и отстаивала именно подход, описанный Робом (прям один в один). Зарубились мы не на шутку, холивар был дикий. Менеджеры даже в какой-то момент не выдержали, и приостановили проект. В итоге команды просто развели по разным углам, позволив каждой работать по своим правилам (к удивлению, это сработало), хотя особенно категоричным людям пришлось уйти (я скучаю, Артур :) ). Вот, что бывает, если одни возводят практику в ранг религии, а другие оказываются агностиками.
Интересен культурный аспект этого конфликта. Гибкий, сложно формализуемый подход «здесь тестирую, а здесь нет; здесь unit, а там интеграционно и т. д.» из статьи — это чисто по-русски; догматический же TDD очень подходит немецком менталитету.
Прошло полтора года. На днях мне пришел отчет с ретры немецкой команды, которая признала (внутри своего коллектива), что была вынуждена отказаться от догматичного следования TDD. Распечатал этот email и повесил над своим столом. Подумывал затребовать официального признания правоты российской стороны, но вряд ли это бы улучшило и без того зыбкое взаимопонимание между командами :) Да и, надо признать, догматичность немцев меня тоже кое-чему научила, заставила серьезнее задумываться о тестировании кода.
Попробуйте поиграться с настройками:
1. Уменьшите количество ядер и потоков, в которых NCrunch запускает тесты
2. Выберите режим запуска только impacted тестов. В NCrunch это пока экспериментальная фича, а вот в Continuous Tests она работает стабильно — можете попробовать перейти на Continuous Tests
Похоже, у вас на все есть свое мнение, и вы не утруждаете себя тем, чтобы синхронизировать это мнение с сообществом (а поставить мне минус в карму при этом, видимо, не поленились). Позвольте откланяться.
То есть в статье, которую вы использовали в качестве пруф-линка, вы нашли подтверждение моим словам (кстати, я назвал тесты мини-интеграционными отсебя, и был приятно удивлен, что Фаулер использует ту же терминологию), и вместо того, чтобы признать мою правоту, решили подменить понятия. Конструктивно — ничего не скажешь.
Я все-таки имел в виду production-like базу данных, а не прям production базу (кто же тестирует на реальной production-базе?).
Допустим, ваше приложение использует MySQL в качестве базы данных. У вас есть два похожих теста. Единственное их отличие заключается в том, что первый тест будет работать со специальной тестовой базой MySQL, а другой — с in-memory базой данных SqlLite. Правильно ли я понимаю, что согласно вашей терминологии первый тест будет интеграционным, а второй — юнит?
А я не вижу принципиальной разницы между production-базой и in-memory базой. И я в упор не понимаю, как использование in-memory базы данных вместо production делает интеграционный тест юнит тестом.
Ненене. Прежде чем спрашивать, вы сперва ответьте. Вы привели эту ссылку, в качестве доказательства своей фразы про юнит-тесты. Но при этом Фаулер ничего не говорит о юнит-тестах, он говорит о разных подходах к TDD
Фаулер здесь говорит о двух подходах к TDD: один подход предполагает использование реальных реализаций там, где где можно обойтись без стабов/моков, а другой подход предполагает стаббинг/моккинг всего и вся. Так вот в первом подходе мы получаем слегка интеграционные тесты, а во втором — классические юнит-тесты.
И мы вновь приходим к тому, что юнит-тесты — это тесты на стабах и моках. И это не байка, это действительность.
Рассуждаю исходя из личного опыта. Я просто ознакомился с этими принципами, осознал, что действительно когда я их раньше нарушал, было плохо. И в итоге стал им следовать. Без какого-либо TDD.
Да, TDD подталкивает к использованию SOLID'а, но по-моему SOLID не такая уж сложная штука, чтобы ее нельзя было осилить без TDD.
Да, все классы зависят от других классов. Да, юнит-тестирование предполагает тестирование в изоляции. Как следствии, юнит-тесты — тесты на моках и стабах. Почему вдруг это стало байкой?
public void Function1()
{
if (lablabla)
Function2();
else
Function3();
}
В Function1 две независимые ветки исполнения. Теперь представим, что Function2 и Function3 имеют ту же структуру. Получаем уже 4 независимые ветки исполнения. В реальных системах глубина вызова таких функций не менее 10. А это уже 2^10 = 1024 независимых ветки исполнения. И это только для одной публичной функции. Покрыть такое количество кейсов acceptance-тестами на Function1 невозможно.
Года полтора назад мы с автором перевода (привет, Артур!), еще будучи коллегами, стали участниками одной интересной заварушки. Несколько лет мы в качестве аутсорсеров успешно сотрудничали с одной немецкой компанией, у которой был, помимо нас, и своей отдел разработки. Все было хорошо, пока в один прекрасный(?) момент немцы не упоролись по TDD. Причем жестко так, классически, догматично. Российская сторона не хотела принимать новые правила игры, и отстаивала именно подход, описанный Робом (прям один в один). Зарубились мы не на шутку, холивар был дикий. Менеджеры даже в какой-то момент не выдержали, и приостановили проект. В итоге команды просто развели по разным углам, позволив каждой работать по своим правилам (к удивлению, это сработало), хотя особенно категоричным людям пришлось уйти (я скучаю, Артур :) ). Вот, что бывает, если одни возводят практику в ранг религии, а другие оказываются агностиками.
Интересен культурный аспект этого конфликта. Гибкий, сложно формализуемый подход «здесь тестирую, а здесь нет; здесь unit, а там интеграционно и т. д.» из статьи — это чисто по-русски; догматический же TDD очень подходит немецком менталитету.
Прошло полтора года. На днях мне пришел отчет с ретры немецкой команды, которая признала (внутри своего коллектива), что была вынуждена отказаться от догматичного следования TDD. Распечатал этот email и повесил над своим столом. Подумывал затребовать официального признания правоты российской стороны, но вряд ли это бы улучшило и без того зыбкое взаимопонимание между командами :) Да и, надо признать, догматичность немцев меня тоже кое-чему научила, заставила серьезнее задумываться о тестировании кода.
1. Уменьшите количество ядер и потоков, в которых NCrunch запускает тесты
2. Выберите режим запуска только impacted тестов. В NCrunch это пока экспериментальная фича, а вот в Continuous Tests она работает стабильно — можете попробовать перейти на Continuous Tests
Допустим, ваше приложение использует MySQL в качестве базы данных. У вас есть два похожих теста. Единственное их отличие заключается в том, что первый тест будет работать со специальной тестовой базой MySQL, а другой — с in-memory базой данных SqlLite. Правильно ли я понимаю, что согласно вашей терминологии первый тест будет интеграционным, а второй — юнит?
И мы вновь приходим к тому, что юнит-тесты — это тесты на стабах и моках. И это не байка, это действительность.
Если вам показалось, что я некорректно использовал термины мок и стаб, постарайтесь объяснить это, а не кидаться ссылкой (пусть даже такой ссылкой).
Ваш изначальный комментарий все еще вызывает у меня недоумение.
Да, TDD подталкивает к использованию SOLID'а, но по-моему SOLID не такая уж сложная штука, чтобы ее нельзя было осилить без TDD.
Да, все классы зависят от других классов. Да, юнит-тестирование предполагает тестирование в изоляции. Как следствии, юнит-тесты — тесты на моках и стабах. Почему вдруг это стало байкой?
public void Function1()
{
if (lablabla)
Function2();
else
Function3();
}
В Function1 две независимые ветки исполнения. Теперь представим, что Function2 и Function3 имеют ту же структуру. Получаем уже 4 независимые ветки исполнения. В реальных системах глубина вызова таких функций не менее 10. А это уже 2^10 = 1024 независимых ветки исполнения. И это только для одной публичной функции. Покрыть такое количество кейсов acceptance-тестами на Function1 невозможно.