Концепция тест-листов в тестовой разработке

Question

В TDD каждый говорит о создании модульных тестов и о том, как осуществляется разработка.Я знаю весь цикл, но никто не говорит о создании этих модульных тестов из требований?Я читал где-то в литературе, что всегда полезно создать список тестов перед разработкой этих модульных тестов.Мой вопрос: Какая именно процедура (шаги) выполнялась перед написанием юнит-тестов в TDD?означает, что написаны ли модульные тесты непосредственно из требований без использования какого-либо формального стандарта или созданы списки тестов до их разработки?

Answer 1

Только список тестов является временным хранилищем для следующих тестовых случаев. Это абсолютно неформально .

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

Нет процедуры для написания тестов и списка, это так же, как при создании модели UML из требований. Вы думаете о проблеме и создаете дизайн. Как только дизайн завершен, вы начинаете реализацию. С TDD вы думаете о проблеме с точки зрения тестирования, вы записываете некоторые тесты в список и начинаете с более простого теста в списке. Вы можете добавить (или удалить) тест в список в любое время.

Эпизод игры в боулинг - это краткое чтение, иллюстрирующее переход от требований к юнит-тестам. Он не упоминает ни одного тест-листа.

Я веду свой список тестов в виде комментариев внизу исходного файла моих модульных тестов.

void test_foobarShallFailWithNull(void) {
...
}
// the tests I *may* write next
//void test_foobarShallFailWhenX(void)
//void test_foobarShallWorkWhenY(void)

Answer 2

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

Answer 3

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

Затем вы работаете со списком, отбирая их один за другим, вычеркивая их, когда они сделаны. Если во время реализации вы предложите несколько новых тестов, добавьте их в список тестов и продолжите фокусироваться на текущем тесте. Когда в вашем списке больше нет тестов, все готово.

Модульные тесты для TDD являются мелкозернистыми, и в большинстве случаев требования / спецификации - нет. Таким образом, вы используете документы с требованиями для разработки приемочных тестов на уровне системы. И чтобы выполнить конкретный приемочный тест, вам нужно выполнить ряд задач, которые вы реализуете с помощью TDD.

Answer 4

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