Это плохая идея, чтобы создавать тесты, которые полагаются друг на друга в тестовом приспособлении?

Question

Например:

// NUnit-like pseudo code (within a TestFixture)

Ctor()
{
 m_globalVar = getFoo();
}

[Test]
Create()
{
 a(m_globalVar)
}

[Test]
Delete()
{
 // depends on Create being run
 b(m_globalVar)
}

… или…

// NUnit-like pseudo code (within a TestFixture)

[Test]
CreateAndDelete()
{
 Foo foo = getFoo(); 
 a(foo);

 // depends on Create being run
 b(foo);
}

... Я пойду с последним и предположу, что ответ на мой вопрос:

Нет, по крайней мере, не с NUnit, потому что согласно руководству NUnit :

Конструктор не должен иметь побочных эффектов, поскольку NUnit может создавать класс несколько раз в течение сеанса.

... также я могу предположить, что это вообще плохая практика? Так как тесты обычно можно запускать отдельно. Таким образом, результат Create может никогда не будет очищен с помощью Delete.

Answer 1

Да, это плохая практика. Во всех известных мне модульных тестах порядок выполнения методов тестирования не гарантируется, поэтому написание тестов, зависящих от порядка выполнения, явно не рекомендуется.

Как вы также заметили, если тест B зависит от (побочных) эффектов теста A, либо тест A содержит некоторый общий код инициализации (который затем следует вместо этого перенести в общий метод настройки), либо эти два теста являются частью одной и той же истории, чтобы их можно было объединить (ИМХО - некоторые люди придерживаются единого утверждения для каждого метода теста, поэтому они не согласились бы со мной по этому вопросу), иначе тест B следует сделать полностью независимым от теста A в отношении настройки прибора .

Answer 2

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

Если ваши тесты требуют выполнения в определенном порядке, вы никогда не сможете быть уверены (по крайней мере, без расследования), провалился ли тест из-за порядка выполнения или проблемы с кодом!

Это в конечном итоге приведет к отсутствию уверенности в отношении вашего набора тестов и возможному отказу от него.

Answer 3

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

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

Лично я бы поставил тестирование конструкторов и деструкторов раньше в моем наборе тестов, чем тестирование поведения построенных экземпляров, но YMMV.