Первый тест TDD без утверждения/ожидаемого исключения. Стоит ли оно того?

Скажем, я начинаю играть с TDD. Это хороший первый тест?

[TestMethod]
public void Can_Start_And_End_Game()
{
    Tetris tetris = new Tetris();
    tetris.Start();
    tetris.End();
}

В основном это заставляет меня определять 3 вещи: класс Tetris и его методы Start() и End(), но, кроме того, это довольно бесполезно. Это может иметь непосредственный интерес, так как с ними я могу определить этот класс и эти методы, но позже он, вероятно, не будет служить какой-либо цели. Его единственная цель могла бы показать, что должно быть возможно начать игру и закончить ее, не получив исключения в середине.

Каковы ваши мысли по этому поводу?

Ответ 1

В основном это заставляет меня определять 3 вещи: класс Тетрис и его методы Start() и End(),

True.

но кроме того, это довольно бесполезно.

False.

позже он, вероятно, не будет служить какой-либо цели

Ложь тоже.

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

И это ОГРОМНОЕ. Эпическая. Монументальная.

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

Этот тест является EPIC.

Ответ 2

В этом тесте вы не занимаетесь разработкой класса Tetris - вы решили, какой должен быть его API, но это хорошо, но почему бы не написать тест, который проверяет что-то, что он должен делать?

Тесты должны сообщать API, а не наоборот (imho).

Ответ 3

Я не большой поклонник этого теста. Да, это помогло определить интерфейс, но он не очень силен для определения (и тестирования) поведения.

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

В идеале каждый метод тестирования выполняет одно поведение.

Ответ 4

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

[TestMethod]
public void Can_Start_And_End_Game()
{
    try
    {
        Tetris tetris = new Tetris();
        tetris.Start();
        tetris.End();
    }
    catch (Exception ex)
    {
        Assert.Fail("Unexpected exception thrown: " + ex.ToString());
    }
}

Ответ 5

Да, тест подтверждает, что в конструкторе не генерируется исключение, метод Start() и Stop().

Я вижу небольшое значение в дополнительном блоке try/catch в тесте для исключения исключений. Инструмент, выполняющий тест, поймает и сообщит об этом. Используя принцип TSTTCPW, тест может обойтись без блока try/catch.

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

Обратите внимание на разницу между написанием unit test и использованием TDD. Значение исходит из понимания этой разницы.

Ответ 6

Как сказал С. Лотт, этот тест охватывает ТОН земли. Это так "стоит", что стоит сломать хотя бы 3 теста и добавить к ним соответствующие утверждения:

[TestMethod]
public void Test_Contructor()
{
    Tetris tetris = new Tetris();
    // make assertions
}

[TestMethod]
public void Test_Start()
{
    // setup
    Tetris tetris = new Tetris();

    // exercise
    tetris.Start();

    // make assertions
}

[TestMethod]
public void Test_End()
{
    // setup
    Tetris tetris = new Tetris();
    tetris.Start();

    // exercise
    tetris.End();

    // make assertions
}