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

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 может создать класс многократно в ходе сессии.

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

8

unit-testing nunit

задан Nick Bolton 8 June 2010 в 12:52

3 ответа

Другие вопросы по тегам:

unit-testing nunit

Похожие вопросы:

score 1 · Answer 1

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

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

В конечном итоге это приведет к тому, что у вас возникнет неуверенность в отношении вашего набора тестов и в конечном итоге он будет заброшен.

score 0 · Answer 2

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

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

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

score 6 · Answer 3

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

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