Дэн Норт предположил, что не существует такого понятия, как тестируемое проектирование, потому что проектирование на самом деле не вытесняется тестированием - что эти модульные тесты становятся тестами только после того, как функциональность реализована, но на этапе проектирования вы действительнопроектирование на примере.
Это имеет смысл - ваши тесты настраивают диапазон выборочных данных и условий, с которыми будет работать тестируемая система, и вы разрабатываете проект на основе этих примеров сценариев.
Некоторые другие ответы предполагают, что это основано на YAGNI.Это отчасти верно.
Помимо этого, существует проблема сложности.Как часто говорят, программирование - это управление сложностью - разбивка вещей на понятные единицы.
Если вы напишите 10 тестов, чтобы охватить случаи, когда param1 равен нулю, param2 равен нулю, string1 пуста, int1 отрицателен,и текущий день недели - выходные, а затем приступить к реализации этого, вам придется сразу же совмещать много сложностей.Это открывает пространство для появления ошибок, и становится очень трудно разобраться, почему тесты не выполняются.
С другой стороны, если вы пишете первый тест, покрывающий пустую строку1, вам едва ли нужно думать ореализация.После прохождения теста вы переходите к случаю, когда текущий день - выходные.Вы смотрите на существующий код, и становится очевидным, куда должна идти логика.Вы запускаете тесты, и если первый тест в настоящее время не проходит, вы знаете, что сломали его, внедрив программу «день недели».Я бы даже порекомендовал вам фиксировать исходный код между тестами, чтобы, если вы что-то сломали, вы всегда могли вернуться в проходящее состояние и повторить попытку.
Делая немного по времени, а затем проверяя, что он работает, значительно сокращаетсяпространство для введения дефектов, и когда ваши тесты дают сбой после реализации, вы изменили настолько мало кода, что очень легко идентифицировать дефект и исправить его, потому что вы знаете, что существующий код уже работал должным образом.