Из того, что я понимаю, в TDD сначала нужно написать провальный тест, затем написать код для его прохождения, затем выполнить рефакторинг. Но что, если ваш код уже учитывает ситуацию, которую вы хотите проверить?
Например, допустим, я использую алгоритм сортировки TDD (это только гипотетически). Я мог бы написать модульные тесты для пары случаев:
вход = 1, 2, 3
выход = 1, 2, 3
вход = 4, 1, 3, 2
выход = 1, 2, 3, 4
так далее...
Чтобы пройти тесты, я использую быструю и грязную пузырьковую сортировку. Затем я делаю рефакторинг и заменяю его более эффективным алгоритмом сортировки слиянием. Позже я понимаю, что нам нужно, чтобы он был стабильным, поэтому я тоже пишу тест для этого. Конечно, тест никогда не будет неудачным, потому что сортировка слиянием - это стабильный алгоритм сортировки! Несмотря на это, мне все еще нужен этот тест, если кто-то снова проведет его рефакторинг, чтобы использовать другой, возможно, нестабильный алгоритм сортировки.
Разве это нарушает мантру TDD всегда писать неудачные тесты? Я сомневаюсь, что кто-нибудь порекомендует мне потратить время на реализацию нестабильного алгоритма сортировки, просто чтобы проверить контрольный пример, а затем переопределить сортировку слиянием. Как часто вы сталкиваетесь с подобной ситуацией и чем занимаетесь?