2015-08-14 1 views
3

У нас есть общий базовый интерфейс public interface IOperation {...} и много (десятки, скоро 100+) разных объектов, которые реализуют IOperation.Внутренние, внутрисетевыеVisibleTo и тестирование общего поведения

У нас также есть тесты для всех тех реализаций, которые наследуются от базовых классов, называемых TestOperationCommon, которые были заархивированы с помощью фактического класса операций и типов для метода Create для new такой операции. У нас есть реализации для TestOperationCommon с одним до пяти параметров шаблона (этого достаточно для всех операций).

Теперь, недавно было принято решение о том, чтобы все реализации операций были внутренними, и только IOperation публично, что кажется хорошей идеей, поскольку эти операторы являются деталями реализации. И с [InternalsVisibleTo(...)] тестирование показалось также решаемым.

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

Inconsistent Accessibility .... less accessible than ...

ошибки. Код ниже, открытый тестовый класс не может наследовать от TestOperationCommon с общим параметром T, который является внутренним. Но дублирование всех этих тестов с общим поведением в конкретных тестах также кажется плохой идеей.

  • Есть ли способ, чтобы получить vstest рамки (VS2013 +), чтобы проверить [TestClass] эс, которые являются внутренними?

  • Или есть другой способ, которым мы можем проводить общие тесты, не дублируя много кода?

  • Или мы делаем это неправильно (что делает эти «детали реализации» внутренними)?

Пример кода как запрос в комментарии:

public interface IOperation { ... } 

internal class SomeOperation : IOperation 
{ 
    public SomeOperation(A a, B b, C c) {...} 
} 


public abstract TestOperationCommon<T, A, B, C> 
    where T : IOperation 
    where ... 
{ 
    protected abstract T Create(A a, B b, C c); 

    [TestMethod] 
    public void TestCommonOperationBehavior() 
    { 
     var op = Create(Mock.Of<A>(), Mock.Of<B>(), Mock.Of<C>); 
     ... 
    } 
} 

[TestClass] 
public class TestSomeOperation : TestOperationCommon<SomeOperation, ...> 
{ 
    [TestMethod] 
    public void TestSpecificSomeOperationStuff() {} 

} 
+0

небольшой пример с кодом поможет много – Backs

+0

Хм, обычная точка такого большого рефакторинга существенно сократить затраты на тестирование. Поскольку нет смысла тестировать что-либо, что обычный клиентский код не может использовать в любом случае. –

ответ

1

Не могли бы вы создаете класс тест-обертку?

Что-то вроде:

[TestClass] 
public class AnnoyingTestSomeOperationWrapper 
{ 

    [TestMethod] 
    public void TestSpecificSomeOperationStuff() 
    { 
     new TestSomeOperation().TestSpecificSomeOperationStuff() 
    } 

} 

internal class TestSomeOperation : TestOperationCommon<SomeOperation, ...> 
{ 
    public void TestSpecificSomeOperationStuff() {} 

} 
+0

Я пробовал это, основная проблема заключается в том, что либо он уродлив, либо мы не получаем приятных сообщений об ошибках тестирования. Если мы пересылаем все шесть методов (каждый в своем собственном [TestMethod], у нас есть много дублирования. И если мы просто создадим один метод, который вызывает все общие методы, у нас много приятных сбоев, которые приводят нас к этой проблеме. – Wilbert

+1

Я пытался выяснить, можете ли вы использовать ILGen/Code Generation для автоматического создания классов-оболочек для вас, но я сомневаюсь, что он будет хорошо играть с VS Test Runner. –

Смежные вопросы