Я вас понял. Действительно, так выглядит логично. Для черезвычайно больших проектов где нет персональной ответственности за определенные модули, это вполне осмысленно.
Про нашу практику скажу, что тесты никто не правил. На это просто не выделялось время. Их отключали.
В результате, время, потраченное на их написание, просто терялось.
Вот мы и докопались до сути: если применять TDD к проекту, который пишется в неподходящей для TDD манере, TDD применяться не будет. Логично, черт побери.
Изумительно сформулировано.
Мне жаль, что не я это сказал.
Во-первых, спасибо за очень содержательный комментарий.
Обе ваши мысли в точку.
У нас действительно была плохая робастность дизайна. И это очень серьезно снижало полезность написанных юнит тестов. То есть, протоколы закрывались, но в процессе разработки и интреграции они могли быть несколько раз поменяны.
Во-вторых, у нас действительно были проблемы из-за позднего тестирования. Правда, TDD нам эти проблемы не решил. Видимо из-за пункта 1.
Согласен. Это две стороны медали:
Пишете так — TDD вам в руки.
Пишете иначе — TDD станет головной болью.
К моему великому сожалению, у нас случился второй вариант. И, вообще говоря, за всю мою 16-летнюю практику, я учавствовал в разработке именно неудобного для TDD кода.
Таким способом мы TDD не использовали. И коучеры нам про это тоже ничего не говорили.
Ну, и как результат, ценность тестов падала по мере роста размера коллектива. Каждый свой тест проверял как понимал задание. Но ошибки в этом понимании переходили в тесты. И тесты сами по себе становились недостоверными.
Скажите, а кто там пишет тесты? И какая у него зарплата?
Собственно, весь вопрос о том, насколько это экономически оправдано.
Разумеется, если писать юнит тесты легко и просто (не мой случай) — то вопрос отпадает.
В посте я пишу, что юнит тесты не предназначены (или плохо это делают) для отлавливания ошибок мультисрединга, интерфейсов и интеграции систем, написанных большим количеством людей.
Если у вас таких ошибок меньшинство, то либо у вас неопытные программисты, которые делают много «ошибок в коде», либо у вас не слишком большие проекты, и мултисрединг за вас решает Фреймворк. Я предполагаю, вы работаете с вебом, так?
По поводу уменьшения затрат на тестирование. Я оного не заметил. Правда, я и не особенно вглядывался — все таки я программист, а не QA. Но я полагаю, что в любом случае, экономия гораздо меньше: в наших палестинах зарплата QA в два-три раза меньше зарплаты программистов.
Поверьте, это далеко не для всех очевидно.
Наш менеджмент свято верил, что юнит-тесты и TDD — панацея от всех багов. А это совершенно не так! Баги бывают разные. И тех, которые юнит тесты не ловят принципиально (в моей практике) — большинство.
Да, там где затраты вырастали в 5 раз — это был особенный АД.
Но даже и в более-менее простых местах, затраты вырастали раза в два.
И это было тоже болезненно.
Я прошу прощения за неопытность.
Это вообще нормально, если я сейчас подредактирую пост и в свое «резюме» вставлю вышеприведенный дисклаймер?
Здесь так делают?
Извините, но я обращу ваше внимание на кусок моего поста.
>Тем не менее, есть 3 вида кода, когда юнит тесты очень даже к месту (два из них я уже упоминал):
>1. ПО повышенной надежности (для атомной электростанции)
>2. Легко изолируемый код – алгоритмы и все такое
>3. Утилиты – код который будет ОЧЕНЬ широко использоваться в системе, так что стоит их досконально прошерстить заранее
Ваш пример подходит под пункт 2. Видите?
Судя по тому, что этот абзац ускользает от внимания читателей, я довольно неудачно оформил свой пост.
Был там и GUI, были и сервисо-подобные процессы (хотя они не были оформлены как сервисы, но занимались backend обработкой задач).
В общем, система была с большим количеством взаимосвязей. И изолировать код можно было только массированным написанием и программированием моков. Собственно, вся моя боль выражена в ячейке таблицы:
>Дополнительные усилия в программировании x2… x5
Я думаю, вы понимаете, что такие вещи не «для ленивых».
Разумеется, это мой кейс. И, как я уже неоднократно говорил, что если код легко изолируется, то функциональные тесты (которые я люблю и уважаю) приближаются к юнит тестам, и различаются только незначительными техническими деталями. Позволю себе скопировать сюда кусок моего поста.
>Разумеется, если код слабо использует другие модули, так что полностью изолировать его очень легко, то юнит тесты практически пересекаются с функциональными тестами и разница между ними только в названии и малозначительных технических деталях.
В таком случае у меня нет возражений против юнит тестов. О чем я тоже уже писал.
>Скажите, пожалуйста, а где в вашем анализе тесты класса «тестируем насквозь всю функциональность,
>кроме внешних зависимостей»? Которые (а) автоматические (б) прекрасно гоняются на билд-машине
>(ц) позволяют тестировать с любыми входными данными и (д) находят ошибки интеграции
>(компонентного уровня?
Вы меня простите, но вы описали столь идеальные тесты, что я такого великолепия в жизни не встречал. Если не брать учебные проекты, разумеется. И соответственно, в моем анализе этого нет.
>И второй вопрос: к системам какого типа вы применяли TDD в частности и автоматизированное тестирование в целом?
Система, состоящая из примерно 10 процессов, связанных друг с другом через СОМ, плюс несколько десятков динамически подгружаемых DLL. Писалась больше десяти лет до нас.
Конечно перебор. У меня ощущение, что меня как-то превратно поняли, как будто я вообще против тестов.
Я в посте написал, что есть 3 ситуации, когда юнит тесты оправданы.
>1. ПО повышенной надежности (для атомной электростанции)
>2. Легко изолируемый код – алгоритмы и все такое
>3. Утилиты – код который будет ОЧЕНЬ широко использоваться в системе, так что стоит их досконально прошерстить заранее
А во всех остальных можно ограничиться каской функциональными тестами. Ибо их писать в целом гораздо проще (по крайней мере согласно моему опыту).
Про нашу практику скажу, что тесты никто не правил. На это просто не выделялось время. Их отключали.
В результате, время, потраченное на их написание, просто терялось.
Изумительно сформулировано.
Мне жаль, что не я это сказал.
Обе ваши мысли в точку.
У нас действительно была плохая робастность дизайна. И это очень серьезно снижало полезность написанных юнит тестов. То есть, протоколы закрывались, но в процессе разработки и интреграции они могли быть несколько раз поменяны.
Во-вторых, у нас действительно были проблемы из-за позднего тестирования. Правда, TDD нам эти проблемы не решил. Видимо из-за пункта 1.
Пишете так — TDD вам в руки.
Пишете иначе — TDD станет головной болью.
К моему великому сожалению, у нас случился второй вариант. И, вообще говоря, за всю мою 16-летнюю практику, я учавствовал в разработке именно неудобного для TDD кода.
Ну, и как результат, ценность тестов падала по мере роста размера коллектива. Каждый свой тест проверял как понимал задание. Но ошибки в этом понимании переходили в тесты. И тесты сами по себе становились недостоверными.
У нас было — С++ в руки и вперед.
И конечно, «ошибки в коде» делают все. Даже я. :)
Но прочих ошибок в системе было больше, о чем я уже писал.
Собственно, весь вопрос о том, насколько это экономически оправдано.
Разумеется, если писать юнит тесты легко и просто (не мой случай) — то вопрос отпадает.
Если у вас таких ошибок меньшинство, то либо у вас неопытные программисты, которые делают много «ошибок в коде», либо у вас не слишком большие проекты, и мултисрединг за вас решает Фреймворк. Я предполагаю, вы работаете с вебом, так?
Наш менеджмент свято верил, что юнит-тесты и TDD — панацея от всех багов. А это совершенно не так! Баги бывают разные. И тех, которые юнит тесты не ловят принципиально (в моей практике) — большинство.
Для всего, что под них не подпадает, под 3 упомянутых случая, мое резюме сохраняет смысл.
Я лично в 90% своей трудовой деятельности имел дело именно с кодом, который для юнит тестов не удобен. Может кому-то везет больше. Рад за них.
Но даже и в более-менее простых местах, затраты вырастали раза в два.
И это было тоже болезненно.
Это вообще нормально, если я сейчас подредактирую пост и в свое «резюме» вставлю вышеприведенный дисклаймер?
Здесь так делают?
>Тем не менее, есть 3 вида кода, когда юнит тесты очень даже к месту (два из них я уже упоминал):
>1. ПО повышенной надежности (для атомной электростанции)
>2. Легко изолируемый код – алгоритмы и все такое
>3. Утилиты – код который будет ОЧЕНЬ широко использоваться в системе, так что стоит их досконально прошерстить заранее
Ваш пример подходит под пункт 2. Видите?
Судя по тому, что этот абзац ускользает от внимания читателей, я довольно неудачно оформил свой пост.
Я добавлю, что честно старался. И мои коллеги тоже (кто-то больше, кто-то меньше). И мы все не осилили.
А компании это стило много, очень много денег.
Так что пост о том, что у TDD (и юнит тестов) есть очень определенные границы, когда их имеет смысл применять.
В общем, система была с большим количеством взаимосвязей. И изолировать код можно было только массированным написанием и программированием моков. Собственно, вся моя боль выражена в ячейке таблицы:
>Дополнительные усилия в программировании x2… x5
Я думаю, вы понимаете, что такие вещи не «для ленивых».
Разумеется, это мой кейс. И, как я уже неоднократно говорил, что если код легко изолируется, то функциональные тесты (которые я люблю и уважаю) приближаются к юнит тестам, и различаются только незначительными техническими деталями. Позволю себе скопировать сюда кусок моего поста.
>Разумеется, если код слабо использует другие модули, так что полностью изолировать его очень легко, то юнит тесты практически пересекаются с функциональными тестами и разница между ними только в названии и малозначительных технических деталях.
В таком случае у меня нет возражений против юнит тестов. О чем я тоже уже писал.
>кроме внешних зависимостей»? Которые (а) автоматические (б) прекрасно гоняются на билд-машине
>(ц) позволяют тестировать с любыми входными данными и (д) находят ошибки интеграции
>(компонентного уровня?
Вы меня простите, но вы описали столь идеальные тесты, что я такого великолепия в жизни не встречал. Если не брать учебные проекты, разумеется. И соответственно, в моем анализе этого нет.
>И второй вопрос: к системам какого типа вы применяли TDD в частности и автоматизированное тестирование в целом?
Система, состоящая из примерно 10 процессов, связанных друг с другом через СОМ, плюс несколько десятков динамически подгружаемых DLL. Писалась больше десяти лет до нас.
Я в посте написал, что есть 3 ситуации, когда юнит тесты оправданы.
>1. ПО повышенной надежности (для атомной электростанции)
>2. Легко изолируемый код – алгоритмы и все такое
>3. Утилиты – код который будет ОЧЕНЬ широко использоваться в системе, так что стоит их досконально прошерстить заранее
А во всех остальных можно ограничиться
каскойфункциональными тестами. Ибо их писать в целом гораздо проще (по крайней мере согласно моему опыту).