Test Driven Development

Недавно искал какой нибудь ИТ-шный видео доклад на вечерок и остановился на докладе от Андрея Солнцева "Пацан накодил - пацан протестил". Возможно название тебе покажется смешным, но доклад очень полезный. В нем объясняется важность и необходимость TDD. Кроме основных постулатов и заповедей TDD на протяжении всего видео автор на примере показывает применение данной практики разработки приложений. Да, я не опечатался, TDD это принцип разработки приложений, а не способ его тестирования. Вторая часть лекции посвящена тестированию UI. Автор показывает как это можно легко сделать при помощи Selenide - фреймворка для тестирования веб-приложений.

Не смотря на то, что лекция была достаточно наглядной, я все же решил немного углубить свои познания Test Driven Development. А что может быть лучше, чем книга, написанная автором данной техники? Правильно, только практика, но начать я решил все же с книги. Как обычно, по ходу чтения я делал выдержки, которые доступны в перечне прочитанных мной книг.

На самом деле я уже больше месяца практикую TDD и только теперь я понял, на сколько этот подход отличается от написания тестов для уже готового кода. Первое серьезное отличие - количество самих тестов. Раньше я покрывал тестами только то, что считал самым важным, а так же только то, что мог! Ведь код, который написан до тестов зачастую довольно сложно протестировать. Меня можно упрекнуть, что я пишу слабо связанный (cohesion) и сильно сцепленный (coupling) код, поэтому его сложно тестировать. Может быть, но как только я начал практиковать TDD эта проблема отпала. Т. е. я получил уже два плюса: пишу менее сцепленный код и у меня покрытие кода тестами растет до написания самого кода (а не перед ревью, когда наступает пора похвастаться показателями).

Едем дальше. Еще один бонус, который мне очень нравится - возможность рефакторить код и при этом не повышать себе кровяное давление. Уровень стресса намного ниже, когда я могу в течении 3-х секунд выяснить, сломал ли я что то пытаясь улучшить код или нет. Но этот fun пропадает, как только дело доходит до legacy code. Если мне нужно внести в него изменения, я беру и пытаюсь покрыть его тестами на столько, на сколько могу. Благо Mockito и PowerMock позволяют делать это довольно легко. После этого я могу вносить свои изменения.

На четвертом месте нашего хит парада достоинств TDD является документация. Тесты, которые я написал - это документация того, как я понял свою задачу. И самое классное то, что эта документация никогда не устареет.

Из недостатков, которые я заметил является время потраченное на задачу. На первый взгляд, оно заметно вырастает и на первых порах это просто раздражает. Особенно когда модифицируемый код не имел до этого своих актуальных тестов. Казалось бы, задача на пол часа, но заповедь TDD должна быть нерушима - сначала тест! В итоге на таску уходит больше времени. Все евангелисты TDD утверждают, что это время с лихвой окупается в долгосрочной перспективе. Конечно для этого нужно что бы все члены команды следовали принципам разработки через тестирование.

P. S. Уже не первый раз я слышу о командах разработчиков, которые обходятся без тестировщиков. Пойми меня правильно, я ничего не имею против классического blackbox тестирования. Меня воодушевляет тот факт, что некоторые разработчики, применяя TDD и парное программирование, настолько уверенны в своем коде, что считают излишним отдавать его на тестирование. Мне кажется это довольно крутая цель к которой следует стремиться.

Comments

Popular posts from this blog

JEEConf 2017 How it was

Java 8 vs GoF: Strategy

Separate and rule your tests