Сначала я думал, что TDD был о тестировании, потом о проектировании. Теперь я убежден, что речь идет об устойчивом мышлении.
Меня зовут Уберто, я пишу тесты.
Я пишу много типов тестов, модульных тестов, интеграционных тестов, приемочных тестов, тестов производительности, дизайна, надежности и т. Д.
Этот пост будет посвящен проверке дизайна написания модульных тестов перед кодом, одним словом, TDD, как определил Кент Бек.
Я впервые услышал об автоматическом тестировании около 2000 года и сразу же пришел в восторг. Я также был соавтором первого фреймворка xUnit с открытым исходным кодом для Borland Delphi, моего основного языка в то время.
Вначале я сосредоточился на аспекте автоматической проверки. С помощью тестов я мог повысить свою уверенность в том, что все работает, как ожидалось. Раньше я разрабатывал новое программное обеспечение с использованием UML, а затем начинал писать тесты для проверки каждого класса перед написанием кода.
Позже я научился использовать сами тесты, чтобы исследовать дизайн в целом. Написание тестов с интерфейсами и макетами до написания одной строчки кода позволяет мне поэкспериментировать и по-настоящему почувствовать, как код будет работать, не тратя время на бумагу и диаграммы. Позже, когда я пишу код, чтобы сделать тесты экологичными, я могу понять критические точки дизайна и улучшить его до завершения первой реализации.
Кстати: я все еще использую бумагу и белые доски для архитектурных схем высокого уровня, но не для проектирования на уровне класса / объекта.
Но недавно я понял, что это не главное преимущество разработки через тестирование.
Давайте сделаем шаг назад и представим, что нам нужно разработать реализацию новой функциональности. Даже если вы просто напишете несколько классов для совместной работы, есть много-много возможностей. Мы можем использовать несколько шаблонов проектирования, мы можем использовать готовые библиотеки, мы должны разобраться, какие структуры данных и как назвать их, чтобы отразить наш домен.
Но по мере того, как мы начинаем писать код, наши альтернативы сокращаются. Это немного похоже на игру Гоу, где у вас есть много возможностей в дебюте, несколько в середине игры и только одна в конце.
Но что, если мы окажемся в плохом положении? В отличие от игры в го, написание кода позволяет нам вернуться к прежним шагам и попробовать другое решение, если мы обнаружим проблему.
Переход от одного решения к другому позволяет очень легко забыть некоторые детали по пути, понять это позже и исправить это, затем попробовать снова безуспешно и, наконец, часами ходить по кругу.
И здесь TDD действительно сияет! Мы можем повторить наши шаги, попробовать другие способы и по-прежнему быть в безопасности с нашим тестовым снаряжением.
Если я не использую тесты для дизайна, я очень тороплюсь писать код, потому что не могу надолго удерживать все детали, которые у меня в голове. Вместо этого TDD доставляет себе удовольствие писать код в своем темпе, с легкостью ума, что я не рискую ничего забыть.
Для сложных задач я обычно пробую как минимум три разных подхода. Подходя к проблеме с разных сторон, я, наконец, чувствую себя намного увереннее в своем решении.
Если Waterfall похож на стиль экспедиции, а программирование Cowboy похоже на свободное лазание, TDD похоже на альпинизм. Безопасно, но все же достаточно быстро.
К сожалению, это то, что мне очень трудно объяснить должным образом, когда я читаю курсы по TDD. Даже когда люди изучают и практикуют TDD, они в основном используют его только для проверки своей первой дизайнерской идеи. Если будет сложно протестировать, что ж ... мы готовы написать массу моков, если это необходимо!
Поэтому, если вы практикуете TDD, пожалуйста, послушайте свои тесты и попробуйте разные решения, прежде чем переходить к одному из них. Таким образом, вы каждый раз будете совершенствовать свои дизайнерские навыки, и Uberto будет гордиться вами, чего бы это ни стоило.
пс. возможно, мне также стоит написать в блоге о Как слушать тесты, Стили TDD и Когда лучше не писать тесты.
