c # одиночное наследование от не-одиночного для интеграционного тестирования

Question

У меня есть таймер в моем классе, который мне нужен только один, поэтому у меня есть статическая ссылка на него в моем Main. Во время интеграционных тестов (не в обычном режиме выполнения) он создается несколько раз в разных тестах.

Моя идея состояла в том, чтобы создать Singleton, который унаследует все функциональные возможности, чтобы обеспечить его наличие. Я бродил, если это разумно, или я столкнусь с некоторыми подводными камнями, о которых я еще не думал?

например, в моем интеграционном тесте я сейчас использую

[TestMethod]
public void SomeTimerTest()
{
    MyTimer t = new Mytimer();
    t.Start();
}

тогда как после этого изменения я бы использовал

[TestMethod]
public void SomeTimerTest()
{
    //creates a new instance or retrieves an already existing one
    MytimerSingleton.Instance.Start();

}

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

Обновление: Исправлена ​​терминология от модульного тестирования до интеграционного тестирования.

Answer 1

Нет. Я бы сказал, что это плохая идея (тм).

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

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

Вместо:

При тестировании класса, использующего ваш таймер, вы должны создать макет вашего класса таймера и передать его тестируемому классу. Затем, если вы нарушите свой класс Timer, тесты класса Timer не пройдут, но все остальные классы все равно пройдут. Отладка - это очень просто, так как вы сразу узнаете, что ваш класс Timer нарушен.

Answer 2

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

Обновление:
Теперь, когда вы прояснили свой вопрос, позвольте мне сказать следующее:

1. Ваши модульные тесты должны быть автономными, это означает, что вы не должны обращаться к файловой системе, так как это снова создает возможность побочных эффектов между вашими тестами.
2. Вы можете ввести метод TearDown, который вызывается после каждого теста. В этом методе вы можете убедиться, что таймер очищен.

Answer 3

Кто может остановить таймер?Если есть только один, то любой вызов Stop () остановит таймер.

Возможно, вам лучше использовать Fixture (например, IUseFixture<> в XUnit.Net), чтобы справиться с этим.

Answer 4

Не могли бы вы реорганизовать свое тестирование?По сути, если вы создаете синглтон, на самом деле может быть только один, поэтому, если ваши тесты требуют нескольких таймеров, вы должны реорганизовать их для работы с уже существующим и активным таймером.