Существуют разные виды тестов: модульные, интеграционные, функциональные и приемочные. Итак, если я занимаюсь разработкой, основанной на тестах, когда я буду писать каждый вид тестов?

Я думаю, что в типичном TDD модульные тесты - это тесты, которые предшествуют написанию кода. Я вижу типичный рабочий процесс:

  1. Ошибка записи модульного теста
  2. Запустите тест, чтобы убедиться, что он не работает
  3. Напишите простейшую функцию / метод передачи
  4. Запустите тест, чтобы убедиться, что он проходит
  5. Код рефакторинга

Таааааааааааааааааааааля этапе интеграционные, функциональные и приемочные тесты? Вы пишете их после кода? Или вы пишете их вместе с модульным тестом в самом начале?

Кроме того, в качестве дополнительного вопроса я часто слышу об идее «100% покрытия кода». Легко увидеть, как это применимо к модульному тестированию - просто создайте по одному тесту для каждого метода. Но стоит ли стремиться к 100% покрытию кода для каждого вида тестов? Например, должны ли модульные тесты покрывать 100% моего кода, а функциональные тесты - 100% моего кода (хотя и с более широкой точки зрения)?

1
Pete 20 Авг 2014 в 18:26

2 ответа

Лучший ответ

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

Статья, иллюстрирующая это: ATDD From the Trenches

Что касается покрытия кода, по моему опыту, вы получаете большую часть его от модульных тестов и / или интеграционных тестов, в зависимости от степени изоляции, которая вам нравится в вашем стиле тестирования. В любом случае, я считаю их дополнительными, вам не следует искать 100% покрытие в каждой категории тестов. С другой стороны, тесты более высокого уровня (системные, сквозные, приемочные ...) обычно устраняют проблемы конфигурации / среды, что обычно не влияет на покрытие кода.

1
guillaume31 20 Авг 2014 в 14:51

Обычно я сначала пишу внешний тест, который будет способствовать развитию функции. Этот подход является частью Лондонской школы TDD.

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

0
ericminio 17 Окт 2014 в 18:50