Разработка, основанная на тестировании, и разработка, основанная на поведении (Ах, да. «Горячие» дебаты в мире разработчиков.) Эта статья не для того, чтобы заставить вас выбирать чью-то сторону, а для того, чтобы обсудить, в каких случаях TDD может быть полезен.
Начнем с краткой истории…
Концепция написания тестов перед программированием впервые была предложена Кентом Беком в конце 90-х. Кент считался экстремальным программистом. В то время эта идея казалась очень диковинной и контрпродуктивной. Большинство разработчиков до этой идеи использовали непрерывную интеграцию/развертывание (CI/CD) и уже внедрили гибкое тестирование.
Отчасти это клеймо сохранилось и сегодня. Хотя TDD широко используется и принят, многие по-прежнему предпочитают другие методы тестирования (например, BDD). В этом нет ничего плохого. Однако знание того, когда и как разработка через тестирование может принести пользу вашей команде, дает много преимуществ.
У меня была эта связь TDD, очень похожая на научный метод, просто «вспыхнувшая» в моей голове однажды ночью, и с тех пор она застряла во мне.
На случай, если вы давно не были вундеркиндом, совершавшим научные открытия (или извергавшим вулканы из научного шоу). Научный метод делает гипотетическое утверждение (гипотезу) о том, как что-то должно реагировать, используя логические рассуждения. Возвращаясь снова и снова на основе новой собранной информации. Позволить окончательному наблюдению или заключению произойти.
Это очень похоже на то, что мы, программисты, делаем правильно?
- Найдите проблему, которую нужно решить,
- Напишите базовый план по ее решению и реализации.
- Затем мы продолжаем возвращаться назад, пока решение не станет масштабируемым, функциональным и работающим должным образом.
В конце концов, мы называем это информатикой…
Это круто и все такое, но КАКИЕ ПРЕИМУЩЕСТВА?!?
- Фундамент уже заложен:
Tests either pass or fail. Writing tests prior to coding allows us to know up-front the expected result. While giving us space to refactor our code (or in this case hypothesis.)
2. Меньше ошибок:
The increased amounts of testing means we can spend less time debugging. Nobody wants to write 1 line and break 30 others.
3. Возможность безопасного рефакторинга кода:
Usually we write the easiest implementation to pass the inital testing. TDD allows us to expand on this implentation safely.
4. Тесты служат дополнительной документацией:
If you've ever hopped into a codebase without documentation, you may have went crazy... Luckily enough, the testing different scenarios involved in TDD makes it easier to understand why things function how they do. Places like LeetCode, HackerRank, and CodeWars use TDD in this exact way!
Теперь, когда мы знаем о многих преимуществах TDD, я думаю, будет справедливо написать статьи о других методах тестирования.
