Как сказать mstest игнорировать тесты в базовом классе, но не в подклассах? - PullRequest
4 голосов
/ 21 ноября 2011

У меня есть анализатор журналов, над которым я работаю, и этот анализатор журналов имеет интерфейс ILogStore, который определяет базовые методы для любого механизма хранения записей журнала (в памяти, в базе данных и т. Д.).Идея состоит в том, что разработчики и пользователи могут добавлять или удалять механизмы хранения журналов через интерфейс плагина MEF.

Однако, чтобы подтвердить, что реализация ILogStore может правильно хранить, фильтровать и извлекать записи журнала, я создал базовый класс для тестирования модуля / интеграции / API:

public class LogStoreBaseTests
{
    protected ILogStore _store;

    [TestMethod]
    public void Can_Store_And_Retrieve_Records() { }

    [TestMethod]
    public void Can_Filter_Records_By_Inclusive_Text() { }

    [TestMethod]
    public void Can_Filter_Records_By_Exclusive_Text() { }

    // etc...
}

Я проверяю свои реализованные задачи, выполняя что-то вроде:

[TestClass]
public class InMemoryLogStoreTests : LogStoreBaseTests
{
    [TestInitialize]
    public void Setup()
    {
        _store = new InMemoryLogStore();
    }
}

Это работает хорошо, за исключением того, что MsTest замечает, что методы в базовом классе имеют [TestMethod], но ошибки, потому что у класса нет [TestClass],чего он не делает, потому что сам по себе это недействительные тесты.

Как я могу сказать MsTest игнорировать методы, когда они не запускаются из подкласса?

Ответы [ 3 ]

13 голосов
/ 22 ноября 2011

Оказывается, MSTest имеет атрибут [Ignore]. Я поместил это и атрибут [TestClass] в свой базовый тест, и он правильно игнорирует методы теста для базовых тестов при использовании методов базового теста при выполнении подкласса

2 голосов
/ 21 ноября 2011

Не уверен, что вы можете указать MS test игнорировать определенные тесты, но вы можете попросить его не запускать определенные категории тестов.

например, следующий атрибут помещает тест в категорию интеграции

[AttributeUsage(AttributeTargets.Method, AllowMultiple = true)]
    public class IntegrationTestAttribute : TestCategoryBaseAttribute
    {
        public IList<string> categories;

        public IntegrationTestAttribute()
        {
            this.categories = new List<String> { "Integration" };
        }

        public override IList<string> TestCategories
        {
            get
            {
                return this.categories;
            }
        }
    }

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

например

[TestClass]
public abstract class BaseUnitTest
{
    public BaseUnitTest(){}
    private TestContext testContextInstance;        
    public TestContext TestContext
    {
        get
        {
            return testContextInstance;
        }
        set
        {
            testContextInstance = value;
        }
    }        
    [TestMethod]
    public void can_run_this_test_for_each_derived_class()
    {
        Assert.IsNotNull(this.ReturnMeSomething());
    }
    protected abstract string ReturnMeSomething();
}

[TestClass]
public class Derived1 : BaseUnitTest
{

    protected override string ReturnMeSomething()
    {
        return "test1";
    }
}

[TestClass]
public class Derived2 : BaseUnitTest
{
    protected override string ReturnMeSomething()
    {
        return null;
    }
}

еще один подход - использовать AOP, как это делает MSTestExtension, код можно найти здесь

0 голосов
/ 21 ноября 2011

Никогда не видел такого подхода, когда одно тестовое устройство наследует другое ... Я бы предложил рассмотреть другой подход, а не работать с такой инфраструктурой тестирования.

Подумайте либо:

  1. Переместите все тесты в один класс, помеченный [TestClass] ИЛИ
  2. Создайте два полностью отдельных теста, чтобы они не были связаны ивлияют друг на друга
...