TDD и «честность» теста

Question

У меня есть проблема с «честностью» теста при выполнении TDD. TDD является

1. WRITE красный тест
2. Написать только достаточно код, чтобы сделать его зеленым
3. Refactor и пусть тест зеленый

До сих пор так хорошо. Теперь вот пример применения принципа выше, такой пример уже был встречен в учебнике & real life:

Я хочу проверить, что текущий адрес электронной почты пользователя отображается на странице по умолчанию моего webapp.

1. Написать красный тест: «example@user.com» отображается в default_page.html
2. Написать только достаточно код, чтобы сделать его зеленым: жёстко «example@user.com» внутри default_page.html
3. Рефакторинг, реализующий get_current_user(), другой код в некоторых других слоях и т. Д., Позволяя тестировать зеленый.

I «шокирован» шагом 2. Здесь что-то не так: тест зеленый, даже если ничего не работает. Здесь присутствует тестовый запах, это означает, что, возможно, в какой-то момент кто-то может сломать производственный код, не нарушая набор тестов.

Что мне здесь не хватает?

Answer 1

Я бы сказал, что то, что у вас есть, только частично завершено. Вы сказали:

Я хочу проверить, что текущий адрес электронной почты пользователя отображается на странице по умолчанию моего webapp.

тест не проверяет адрес текущих пользователей электронной почты на странице по умолчанию, он проверяет, что фиксированный адрес электронной почты «example@user.com» в странице.

Для решения этой проблемы вам необходимо предоставить больше примеров (например, иметь несколько тестов с разными адресами электронной почты) или случайным образом генерировать адрес электронной почты в тестовой настройке.

Так что я бы сказал, что у вас есть что-то, как это псевдо-код:

Given current user has email address "example@user.com" 
When they visit the default page 
The page should contain the email address "example@user.com" 

Это первый тест, который вы можете написать в TDD, и вы можете действительно жёстко это, чтобы избежать реализации ненужных вещей. Теперь вы можете добавить еще один тест, который заставит вас реализовать правильное поведение

Given current user has email address "example2@user.com" 
When they visit the default page 
The page should contain the email address "example2@user.com" 

Теперь вы должны удалить жестко прописывать, как вы не можете удовлетворить оба этих тестов с жёстко solution.So это заставит вас, чтобы получить действительный адрес электронной почты от текущего пользователя и отображение этого.

Часто имеет смысл привести к 3 примерам в ваших тестах. Этим не нужно быть 3 отдельными тестами, вы можете использовать тесты, управляемые данными, для повторного использования одного и того же метода тестирования с разными значениями. Вы не говорите, какую тестовую структуру вы используете, поэтому я не могу привести конкретный пример.

Этот подход распространен в TDD и называется triangualtion.

Answer 2

Вы правильно о

шаг 2. Существует что-то здесь не так

, но это не в TDD подходе. ИМХО это в логике тестирования. После этого (шаг 2) проверяется правильность работы тестового жгута. То, что новый тест делает , не ошибочно проходит, не требуя нового кода и что требуемая функция еще не существует.

Что мне здесь недостает?

Этот шаг также должен тестирует тест сам, отрицательно: это исключает возможность того, что новый тест всегда проходит, и, следовательно, ничего не стоит. Новый тест также должен потерпеть неудачу по ожидаемой причине. Очень важно, чтобы этот шаг повышал уверенность разработчика в том, что он тестирует правильную вещь и проходит только в предусмотренных случаях.

Answer 3

Ваше утверждение, что «ничего не работает» неверно. Код корректно функционирует для случая, когда адрес электронной почты example@user.com. И вам не нужен этот последний рефакторинг. Следующим неудачным тестом может быть отказ в том, что у пользователя есть другой адрес электронной почты.