Используете ли вы TestInitialize или конструктор класса теста для подготовки каждого теста? и почему? - PullRequest
61 голосов
/ 02 декабря 2008

Этот вопрос касается модульного тестирования в Visual Studio с использованием MSTest (это важно из-за порядка выполнения MSTest ). И метод, помеченный как [TestInitialize], и ​​конструктор класса теста будут выполняться перед каждым методом теста.

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

Ответы [ 8 ]

49 голосов
/ 16 августа 2011

Конструктор - это просто структура, предоставляемая языком. Кажется, что каждая тестовая среда имеет свой собственный контролируемый жизненный цикл «инициализация». Вероятно, у вас будут проблемы только при использовании конструктора для изменения ваших местных жителей.

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

public class TestsForWhatever
{
    public TestsForWhatever()
    {
        // You get one of these per test method, yay!
    }

    [TestInitialize] 
    public void Initialize() 
    {
        // and one of these too! 
    }

    [TestMethod]
    public void AssertItDoesSomething() { }

    [TestMethod]
    public void AssertItDoesSomethingElse() { }
}

MSpec: Вы получаете только один Establish и Because для всех ваших утверждений (It). Таким образом, не мутируйте своих местных жителей в своих утверждениях. И не зависит от мутаций местных жителей в базовых контекстах (если вы их используете).

[Subject(typeof(Whatever))]
public class When_doing_whatever
{
    Establish context = () => 
    { 
        // one of these for all your Its
    };

    Because of = () => _subject.DoWhatever();

    It should_do_something;
    It should_do_something_else;
}
17 голосов
/ 31 декабря 2011

Вот некоторые преимущества, которые я нашел с TestInitialize.

  • Некоторые переменные среды (например, TestContext) не доступны до тех пор, пока не будет создан экземпляр класса теста.
  • Может потребоваться реализация с производным классом путем пометки базового метода TestInitialize абстрактным.
  • Может легко переопределить базовый метод TestInitialize и определить, вызывать ли базовый impl перед производным impl, после или вообще. Напротив, если вы извлекаете тестовый класс из базового тестового класса, в случае конструктора без параметров будет вызываться базовый ctor, независимо от того, планировали вы это или нет.
  • Его явное определение проясняет намерения и дополняет метод TestCleanup. Вы можете утверждать, что вы можете создать деструктор для каждого конструктора, но не гарантируется, что MS Test будет обрабатывать деструкторы, как вы ожидаете.
15 голосов
/ 11 февраля 2011

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

4 голосов
/ 13 января 2009

Я предпочитаю использовать метод [TestInitialize] для создания экземпляров тестируемого объекта и его параметров. Я выполняю работу в конструкторе только в том случае, если необходимо создать экземпляр базового класса тестирования (в котором обычно создаются или обновляются репозитории и т. Д.). Это помогает мне логически и физически отделить код тестового фрейма от тестового кода.

3 голосов
/ 25 июня 2010

Этот вопрос также задается (позже) на В чем разница между использованием конструктора в платформе VS Testing и атрибутом TestInitialize ()?

FWIW Я предполагаю, что под «конструктором класса» вы подразумеваете конструктор экземпляра (не статический конструктор ).

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

1 голос
/ 24 июля 2017

Я говорю, используйте конструктор, если вам не нужно TestContext.

  1. Если вы можете все упростить, почему бы и нет. Конструктор проще, чем магический атрибут.
  2. Вы можете использовать readonly, что очень важно при инициализации тестов, когда вы хотите подготовить материал для тестов, который они не должны изменять (в идеале материал, который вы готовите, тоже будет неизменным).
1 голос
/ 02 декабря 2008

Объект, который вы тестируете, не нуждается в создании экземпляра в методе [TestInitialize]. Вы можете проверить конструктор вашего объекта в методе test [Test].

Объект в [TestInitialize] может быть для настройки вашего постоянного хранилища или для подготовки значения, которое тестируемый объект будет использовать в тестах.

0 голосов
/ 10 марта 2017

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...