При применении TDD, какую эвристику вы используете для выбора следующего теста?

Question

Первая часть цикла TDD - выбор теста для сбоя. Я хотел бы создать вики сообщества об этом процессе выбора.

Иногда выбор теста для начала очевиден, начните с низко висящих фруктов. Например, при написании парсера, простой тест для начала - это тест, который не обрабатывает ввод:

def testEmptyInput():
  result = parser.parse("")
  assertNullResult(result)

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

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

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

Как выбор теста связан со стратегиями сверху вниз и снизу вверх? Кто-нибудь может порекомендовать статьи, в которых рассматриваются эти стратегии в отношении TDD?

Answer 1

Для начала я выберу простой типичный случай и напишу для него тест.

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

В противном случае я буду искать то, что должна делать рассматриваемая функция, но не делает.

Answer 2

Я начинаю с привязки самого ценного поведения кода.

Например, если это валидатор, я начну с того, что он говорит, что действительные объекты ценны. Теперь мы можем продемонстрировать код, научить пользователей не делать глупостей и т. Д. - даже если валидатор никогда не будет реализован. После этого я начинаю добавлять крайние случаи, в первую очередь с самыми опасными ошибками проверки.

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

Я также следую практике BDD называть тесты should - так что для вашего примера у меня будет shouldReturnNullIfTheInputIsEmpty(). Это помогает мне определить следующую самую важную вещь, которую должен делать код.

Это также относится к BDD "снаружи-внутрь". Вот пара постов в блоге, которые я написал, которые могут помочь: Pixie Driven Development и Bug Driven Development . Разработка, основанная на ошибках, помогает мне понять, какой должен быть следующий набор функций на системном уровне, который затем помогает мне найти следующий модульный тест.

Надеюсь, это дает вам немного другую перспективу, в любом случае - удачи!