Когда останавливаться при попытке написать содержательные тесты с использованием TDD?

Question

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

Допустим, нам нужно написать метод, который принимает только некоторые строки, он может принимать только строки ['red', 'green', 'blue'], этотребуется и не может быть пустым.

Я пишу первый провальный тест, делаю его зеленым и так далее, и так далее, пока у меня не появятся тесты:

it('should accept red input', () => { /*...*/ }
it('should accept green input', () => { /*...*/ }
it('should accept blue input', () => { /*...*/ }
it('should not accept null input', () => { /*...*/ }
it('should not accept empty input', () => { /*...*/ }

На этом этапевсе проходит, теперь я должен назвать это днем ​​и пойти или я должен пойти и добавить тест, если он не проходит для Purple?Имеет ли смысл добавить этот тест?Если это так, я все еще могу назвать другие 10 цветов для проверки. Должен ли я их тоже рассмотреть?

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

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

Answer 1

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

В вашем примере я бы разбил егодо четырех тестов:

1. Должен принимать цвет в ожидаемом пространстве ввода, например, «красный»
2. Не должен принимать цвет, не в ожидаемом пространстве ввода, например, «фиолетовый»
3. Не следует принимать пустой ввод
4. Не следует принимать пустой ввод

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

Answer 2

В этот момент все проходит, теперь я должен назвать это днем ​​и пойти или я должен пойти и добавить тест, если он не проходит для Пурпурного?Имеет ли смысл добавить этот тест?Если это так, я все еще могу назвать другие 10 цветов для тестирования, стоит ли мне их тоже учитывать?

Один из подходов к улучшению вашей оценки объекта тестирования без перечисления всего мира - это тестирование на основе свойств.Скотт Влашин написал хорошее введение в технику .

. Кент Бек известен тем, что обращал внимание на дублирование данных между тестом и реализацией, и Дж. Б. Рейнсбергер предположил, что в рамкахваша работа по удалению дубликатов, данные имеют тенденцию двигаться к тесту.Так что же это значит?

В вашем случае звучит так, как будто вы можете разделить испытуемый объект на две части - одна часть выглядит как база данных (карта, справочная таблица) имен цветов,другая часть - некоторая логика, которая делает что-то интересное, учитывая базу данных имен цветов.

В последней части вы получаете тесты типа «дано база данных [красный, зеленый, синий], принимает ли субъект тестапуть «это не цвет», когда вход пурпурный; при наличии базы данных [красный, зеленый, синий, фиолетовый] испытуемый выбирает путь «это цвет», когда ввод пурпурный ».

Это оставляет вас с базой данных для беспокойства.Что вы хотите быть осторожным, так это тот факт, что простое тестирование того, что вы ввели одинаковые данные в двух разных местах, не особенно ценно.

Вы также можете рассмотреть это наблюдение из Бек

Мне платят за работающий код, а не за тесты, поэтому моя философия заключается в том, чтобы как можно меньше тестировать, чтобы достичь заданного уровня достоверности

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

Answer 3

Хороший ответ здесь: Существует ли такая вещь, как чрезмерное модульное тестирование?

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

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

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