Недостаток пропаганды TDD, на мой взгляд, - в утрировании принципа test first, его аксиоматизации и возведении на пъедестал, где он приобретает абсурдный вид. По крайней мере, так его часто подают в статьях. Такой подход совершенно естественно вызывает скептицизм практикующего программиста, поскольку написание теста сначала имеет свои неудобства - например, невозможность пользоваться IntelliSense при вызове методов класса. (Кстати, Resharper решает эту проблему.) Поэтому понять прелесть подхода часто можно только попробовав его на практике. Принцип "test first" нужно использовать не как догму, а как мощный инструмент, который качественно меняет подход к разработке ПО, но имеет свою область применения, если смотреть на него в контексте полного цикла разработки.
Отражение взгляда на тесты как на нечто очень важное я нашел в статье о тестировании в Microsoft. О значении, которое там придается тестам, говорят следующие факты:
- позиция тестировщика называется Software Design Engineer in Test
- число тестеров на 40% больше, чем число разработчиков
- планы тестирования внушительны (отрывок)
- тесты изначально автоматизированы
В общем, совершенно согласен с таким подходом, и рад, что мой взгляд на тесты как на что-то первостепенное, находит подтверждение в методике разработки софтверного гиганта.
5 comments:
Скорее, тесты не определяют, а могут скорректировать дизайн...
На мой взгляд - это зависит от того, как к ним подходить. Вполне возможно (и даже удобно) использовать тесты именно на первой стадии проектирования. В совокупности с другими техниками, конечно.
А вот лично мне TDD кажется каким-то искусственным подходом.
Я бы сказал, что тесты, _может быть_ разумно написать тогда, когда уже есть диаграммы классов, диаграммы последовательностей.. Когда архитектура разработана.
А вообще тесты, наверное, имеет смысл писать параллельно с разработкой. Грубо говоря, пишешь функцию - напиши на нее тест сразу. Или, если хотите, сначала определил сигнатуру функции, затем написал тест, затем реализовал функцию в классе. Такой вот, своего рода TDD получается.
И польза очевидна: покрытие кода тестами близко к идеальному :)
К ТДД - в том виде, как его преподносят во многих статьях, - я и сам отношусь скептически. Проблема в том, что все сводится как правило к слепому следованию принципу "написать тест, предже чем делать что-либо". При этом не объясняются причины, почему это работает, и область применения метода. Такой подход легко довести до абсурда.
Между тем, метод очень эффективен, если его применять правильно и по назначению.
Например, я не думаю, что этот метод будет эффективен при разработке интерфейсов. А вот при разработке невизуальных классов, тем более - фрэймворк (библиотеки, предназначенной для решения не конкретной задачи, а класса задач), такой подход подходит идеально; позволяя решить проблемы проектирования, повысить эффективность разработки, уровень качества, лучше справляться со сложностью, и т.д., и даже улучшить документацию кода.
Еще одна проблема метода в том, что его применение требует определенной дисциплины, специальных инструментов, а также навыков проектирования и анализа, - что ограничивает его применимость.
И - да, согласен с тем, что тесты нужно начинать писать после стадий анализа и проектирования; либо - на стадии проектирования, итеративно, параллельно с UML диаграммами.
Post a Comment