При разработке unit тестов в Visual Studio часто хочется создать какой-то базовый клас для тестирования базовой лоники. Например у нас есть такой класс:
[TestClass]
public class PersonTestBase
{
[TestMethod]
public virtual void GetNameTest()
{
//...
}
}
и его класс наследник:
[TestClass]
public class CustomerTest: PersonTestBase
{
[TestMethod]
public override void GetNameTest()
{
base.GetNameTest();
}
}
Плюсы такого подхода:
- полная поддержка визуальных средств Visual Studio (Test List Editor);
- простота реализации.
Минусы:
- избыточность кода;
- создание наследника является по сути copy&paste.
Сразу необходимо заметить, что
PersonTestBase и
CustomerTest должны находится в одной сборке, иначе тесты в
PersonTestBase работать не будут - это ограничение unit тестов. Подробнее смотрите в
msdn. Кроме описанных в msdn способов можно поступить так:
- создаётся два проекта: BaseTests и CustomTests;
- в проект CustomTests добавляются необходимые файлы из BaseTests таким образом: Project -> Add Existing Item -> Выбираем необходимые файлы -> Add As Link.
Таким образом физически файлы находятся в разных проектах, но при компиляции необходимые классы оказываются в одной сборке.
Теперь пришло время изменить наш CustomerTest.
[TestClass]
public class CustomerTest: PersonTestBase
{
[TestMethod]
public override void CustomerTestMethod()
{
//...
}
}
Мы добавили новый, специфический для Customer, метод и удалили переопределения метода из базового класса, т.к. его функциональность нас полность устраивает. Что мы из этого получили:
- фактически, в классе у реализоано 2 тестовы метода: один перешел из базового класса и один мы реализовали сами.
- Visual Studio Test List Editor говорит что у нас только один тетовый медов - метода из бащового класс не отображается и, соответственно, не запускается.
Обидно, но не смертельно. На помощь нам приходит штатная утилита
MSTest , которая решает все, или почти все, наши проблемы.
Плюсы такого метода:
- мы избавились от минусов предыдущего метода;
Минусы:
- нету интеграции с Visual Studio.