Процедура TDD для написания тестов для функции с несколькими путями выполнения

Question

Во время разработки, основанной на тестировании, я наткнулся на функцию, которую мне нужно написать, которая похожа на следующую:

public MyClass DoSomething(string value)
{
    SomeClass existCheck = repository.Get(value);

    if(existCheck == null)
        throw new InvalidOperationException("SomeClass must exist to do something");

    if(existCheck.MyClass != null)
        return existCheck.MyClass;

    MyClass myClass = new MyClass()
    {
        // create object
    };

    return myClass;
}

Используя TDD, мне нужно было бы написать отдельные тесты для

1. Утверждение о том, что сгенерировано исключение
2. Утверждение о том, что существующий SomeClass возвращается
3. Утверждение о том, что новый MyClass возвращается

Я пишу all сначала три теста, затем кодирую их или я пишу каждый тест, затем кодирую функциональность в функции, необходимой для прохождения теста, а затем пишу следующий тест и код, функциональность и т. Д .?

Answer 1

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

1. Напишите тест для сценария existCheck == null, который потерпит неудачу (красный свет)
2. Выполните необходимую работу для сценария 1 доуспешно, и повторно запустите тест (зеленый свет)
3. Напишите второй тест для сценария existCheck.MyClass! = null, который потерпит неудачу.Это часто можно сделать, скопировав первый тест и изменив его.
4. Измените метод так, чтобы оба теста 1 и 2 прошли.
5. Повторите шаги 3 и 4 для окончательного пути выполнения.

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

Answer 2

Основной рабочий процесс TDD: красный / зеленый / рефактор :

1. Сначала напишите тест, он должен провалиться (красный).

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

3. Выполните рефакторинг производственного кода, сохранив зеленый цвет status.

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

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

Answer 3

Напишите отдельный тест для каждого ожидаемого поведения.

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

Редактировать - Отвечая на вопрос, который фактически был задан ...

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

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

Answer 4

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