Когда я впервые услышал о разработке через тестирование (TDD), я сразу же списал ее как метод, который замедлит меня. Как же я должен точно знать, как будет выглядеть мой код, если я часто выполняю рефакторинг во время кодирования? Кроме того, я много лет кодирую и понимаю, как писать код, который «легко» тестируется. Для меня имело смысл игнорировать эту безумную идею.
Тогда я понял, что TDD не означает, что я думал, что это значит. Когда мне впервые объяснили TDD много лет назад, мне сказали: «Сначала ты пишешь все свои юнит-тесты», и это то, что застряло у меня. Даже сейчас, когда я спрашиваю разработчиков, что они понимают о TDD, это ответ, который я получаю.
Так что же такое TDD?
Разработка через тестирование — это процесс итеративного программирования, при котором вы пишете одиночный модульный тест, а затем пишете код, если необходимо, чтобы выполнить тест. Когда тест пройден, вы переделываете код, включая тесты, перед написанием следующего теста.
Доступны более полные определения, но я обнаружил, что этого определения достаточно, чтобы начать разговор, когда разработчики впервые сталкиваются с этим принципом.
Вам также могут понравиться: 4 совета по внедрению тестовой разработки (TDD)
Как практиковать TDD
Что убедило меня попробовать TDD, так это чтение книги «Чистый кодер: кодекс поведения для профессиональных программистов » Роберта К. Мартина (дядя Боб) . Книга посвящает главу TDD и другую главу о практике TDD, где упоминается код игры для игры в боулинг, которую дядя Боб использует для демонстрации TDD. Нахождение этой демонстрации в Интернете и следование за ней было введением в TDD, которое я пропустил. Попробуйте сами, а затем попробуйте применить рабочий процесс к небольшой проблеме с помощью известного решения.
Преимущества TDD
Это то, что я обнаружил за месяц практики TDD в разных контекстах.
Это странно естественно
Так как я начал практиковать написание юнит-тестов в начале своей карьеры, всякий раз, когда я обнаруживал ошибку, у которой не было теста, я создавал новый тест, чтобы сначала воспроизвести ошибку, а только потом менять код программы, пока у меня не появится зеленая сборка. , Оказывается, я делал TDD для ошибок все время.
Это может быть интересным
Было время, когда написание модульных тестов было намного интереснее, чем написание кода функции. TDD предлагает уникальный способ сделать ваше путешествие по менее интересному коду более полезным.
Это хороший способ подобрать старый набор инструментов
Прошло много времени с тех пор, как я написал Java, когда я начал снова, первым делом я создал код-ката, чтобы попробовать TDD. Это заставило меня немедленно рассмотреть инструменты, необходимые для тестирования, а не застрять в конце. Количество раз, когда я говорил менеджеру, что все идет по графику, и только после того, как инструменты модульного тестирования сорвут его с работы в конце долгого дня, когда давление было слишком велико, вероятно, будет выше, чем я хотел бы признать.
Это отличный способ выучить новый язык
«Hello world» — это основной элемент запуска нового языка программирования, но, возможно, он не добавляет достаточной ценности для разработчиков, которые много лет занимались программированием. Рассмотрим эту программу на Python.
питон
1
print(“Hello world!”)
Возможно, мы могли бы узнать больше о новом языке программирования, если бы наше первое приложение было:
питон
xxxxxxxxxx
1
import hello
2
import unittest
3
4
class TestHello(unittest.TestCase):
5
def test_hello(self):
6
result = hello.hello_world()
7
self.assertEqual(result, 'Hello world!')
8
9
if __name__ == '__main__':
10
unittest.main()
питон
1
def hello_world():
2
return "Hello world!"
Это улучшает дизайн
Каждый раз, когда разработчик говорит, что не знает, как протестировать функциональность, я предполагаю, что это проблема дизайна, и часто это так. Даже с моим собственным кодом мне приходилось много раз проводить рефакторинг, когда я начинал писать тесты, потому что некоторые пути было сложно протестировать. TDD решает эту проблему, делая рефакторинг частью вашего цикла разработки.
Это улучшает оценки
The number of teams I still encounter who do not write unit tests and rely completely on manual tests is weirdly high. When these teams start writing tests I find that their estimates can be overly optimistic. Forcing you to think about the tests you will be writing during feature development rather than it being “something you do at the end” helps you mentally keep the whole process in your head.
It’s Excellent for Pair Programming
With ping-pong pair programming two developers work together at the same PC. Developer A writes a failing unit test and then Developer B writes the code to make the test pass. Developer B will then write the next failing unit test and Developer A will write the code to make the test pass. It’s a fun way to challenge each other during pair programming and an excellent tool for teaching when a senior and junior developer pairs.
When the Feature Is Complete, so Are Your Unit Tests
This goes without saying, but it feels so satisfying when your tests are completed when you have finished your last bit of feature code. Maybe a bug will be found later, but you will always write the test before proceeding to write more feature code.
Final Thoughts
With information being freely available we are in a unique position to learn from people without ever having met them. In my case, Uncle Bob helped me understand TDD and try it in a safe, zero consequence environment, and it turned out I enjoy TDD.
We should always be trying new ideas and decide if we want it to be part of our workflow. The important thing is to try it for long enough to form an unbiased opinion.
Further Reading
TDD Example in Software Development (Part I)