TDD - Когда можно написать тест без сбоев? - PullRequest
8 голосов
/ 11 декабря 2008

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

Например, допустим, я использую алгоритм сортировки TDD (это только гипотетически). Я мог бы написать модульные тесты для пары случаев:

вход = 1, 2, 3
выход = 1, 2, 3

вход = 4, 1, 3, 2
выход = 1, 2, 3, 4
так далее...

Чтобы пройти тесты, я использую быструю и грязную пузырьковую сортировку. Затем я делаю рефакторинг и заменяю его более эффективным алгоритмом сортировки слиянием. Позже я понимаю, что нам нужно, чтобы он был стабильным, поэтому я тоже пишу тест для этого. Конечно, тест никогда не будет неудачным, потому что сортировка слиянием - это стабильный алгоритм сортировки! Несмотря на это, мне все еще нужен этот тест, если кто-то снова проведет его рефакторинг, чтобы использовать другой, возможно, нестабильный алгоритм сортировки.

Разве это нарушает мантру TDD всегда писать неудачные тесты? Я сомневаюсь, что кто-нибудь порекомендует мне потратить время на реализацию нестабильного алгоритма сортировки, просто чтобы проверить контрольный пример, а затем переопределить сортировку слиянием. Как часто вы сталкиваетесь с подобной ситуацией и чем занимаетесь?

Ответы [ 12 ]

0 голосов
/ 26 января 2009

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

У меня есть двухэтапное решение:

  1. После того, как у вас есть рабочий код и проверенный тест, преднамеренно вставьте изменение в код, чтобы тест не прошел.
  2. Вырежьте это изменение из исходного кода и поместите его в комментарии - либо в методе кода, либо в методе теста, так что в следующий раз, когда кто-то захочет убедиться, что тест все еще обнаруживает ошибки, он знает, что делать. Это также служит доказательством того, что вы подтвердили, что тест не прошел. Если он самый чистый, оставьте его в методе кода. Возможно, вы даже захотите воспользоваться этим условием, чтобы использовать условную компиляцию для включения тестовых прерывателей .
0 голосов
/ 12 декабря 2008

Но что, если ваш код уже учитывает ситуацию, которую вы хотите проверить?

Разве это нарушает мантру TDD всегда писать неудачные тесты?

Да, потому что вы уже нарушили мантру написания теста перед кодом. Вы можете просто удалить код и начать все сначала, или просто принять тест, работающий с самого начала.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...