Из всех людей я никогда не думал, что буду говорить об этом именно я. Будучи стойким сторонником и практикующим TDD в течение очень долгого времени, мне всегда было интересно, почему все согласны с тем, что это хорошая вещь, и до сих пор не хотят или не могут ее использовать.
Теперь, я думаю, я знаю ответ
Что такое разработка через тестирование (TDD)?
TDD возник из XP (eXtreme Programming Practices) и ориентирован на написание кода модульного тестирования перед написанием рабочего кода. Он состоит из 3 простых шагов
- Напишите примеры неудачных модульных тестов перед написанием любого производственного кода.
- Напишите рабочий код для прохождения тестов
- При необходимости выполните рефакторинг кода
< Repeat />
Это просто и, если делать это добросовестно, может значительно повысить качество исходного кода, по крайней мере, с точки зрения обработки ошибок и управления непредвиденными сценариями.
Мой взгляд на модульное тестирование
Я ярый сторонник тестирования программного обеспечения всеми возможными способами, и модульное тестирование играет огромную роль в проверке функциональной прочности программного обеспечения. Я также рассматриваю модульное тестирование как часть работы по разработке, а не как отдельный элемент работы.
Помните, что мы не можем потрогать, понюхать или ощутить программное обеспечение, чтобы определить его качество. Существует один и только один способ убедиться в качестве программного обеспечения, а именно путем тестирования
Так что такие практики, как TDD, имеют смысл, верно?
Да, черт возьми!
Безусловно, это единственная практика, которая требует тестирования всего производственного кода перед его публикацией. если мы не напишем тест раньше, после того, как подумаем о нем, мы не сможем сделать так же справедливо, как первый.
Значит, люди ДОЛЖНЫ использовать его в больших количествах?
Хм, на этот вопрос сложно ответить, но нетрудно догадаться.
Как человек, который очень ценит модульное тестирование, я могу сказать, что следую TDD. Но если честно, я не могу сказать, что я написал все тестовые примеры до того, как написал свой рабочий код. Чаще всего все наоборот: я пишу рабочий код, а затем код модульного теста
И у меня нет оснований полагать, что это мой уникальный опыт, это ДОЛЖНО БЫТЬ верно для большинства разработчиков программного обеспечения по всему миру.
Так что же мешает писать ТЕСТ перед созданием кода?
Ответ
Человеческое воображение
Нигде в мире, ни в одной другой дисциплине люди не создают инфраструктуру тестирования или тесты, не зная, что именно они собираются тестировать. И никто, абсолютно никто не возьмется за такое задание.
Та же проблема существует и при подходе «Сначала тест».
Написание тестового примера означает сначала вообразить решение и написать тест для этого воображения.
Как разработчик программного обеспечения, мы все знаем, что существует разница между Imagination and Reality. И когда наша реальность отличается от той, которую мы представляли ранее, уже написанные тесты становятся недействительными, и нам нужно снова написать новые тестовые примеры на основе new reality.
Давайте разберемся в этом простыми словами
Предположим, что мы хотим создать беседку и представили, что для этого потребуется всего 4 столба. Вот как может выглядеть ваше воображение
И на основе этого воображения вы написали тестовые примеры, то есть модульные тестовые примеры для беседки с 4 колоннами
Однако, когда вы в конечном итоге создадите то же самое, вы поймете, что вам нужно 8 столбов, а не 4. Вот как могла бы выглядеть настоящая беседка
Большинство написанных ранее тестовых примеров теперь недействительны, и нам нужно написать новый набор тестовых примеров.
Это и есть точная причина, почему люди в конечном итоге пишут тестовые примеры после написания рабочего кода, даже если они все время думают о тестировании.
Чтобы быть справедливым по отношению к разработчикам по всему миру (включая меня), в большинстве случаев у нас может быть 4–5 возможных способов сделать что-то, и нам сначала нужно выбрать способ, прежде чем писать тестовые примеры.
Это означает, что расплывчатые идеи должны быть конкретными
Некоторые могут возразить, что при написании меньших единиц, известных как функции, это может быть не так, но, к сожалению, это НЕ так.
Попробуйте подумать о 10–20 словах, пока пишете электронное письмо/письмо. Ваша настоящая грамматика, а также расположение текста будут меняться большую часть времени.
ОК, это значит, что TDD не подходит, нам нужно после написания кода написать тест, верно?
Нет, идея TDD благородна, и мы должны заставить ее работать.
Хорошо, как?
Ну, мы можем писать тесты после написания <PseudoCodes/> , псевдокод может помочь нам понять конкретные реализации, которые мы планируем сделать, поэтому TDD все еще может работать, но необходимо добавить дополнительный шаг во весь процесс TDD.
- Напишите псевдокод для предлагаемой реализации
- Написать неудачные тестовые случаи на основе псевдокода.
- Напишите производственный код, чтобы пройти неудачные тестовые случаи.
- При необходимости выполните рефакторинг
<Repeat/>
Добавив новый шаг, мы достигнем цели, лежащей в основе создания разработки через тестирование.
Надеюсь, эта статья поможет вам расширить горизонт своих знаний
Спасибо за прочтение…!!!
Дакша
