Unit Тестирование класса с помощью внутреннего конструктора

У меня есть класс под названием "Сессия", который предоставляет несколько общедоступных методов. Я бы хотел, чтобы Unit Test, но в процессе производства мне нужно было контролировать создание экземпляров объектов "Сессия", поэтому делегировать конструкцию классу SessionManager и сделать внутренний конструктор сеанса.

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

Какой лучший способ справиться с этим?

Приветствия,

Lenny.

Ответы

Ответ 1

Ничто не мешает вам тестировать внутренности. Просто сделайте внутренности вашего кода видимыми для набора тестов, используя атрибут InternalsVisibleTo: в AssemblyInfo добавьте

[assembly:InternalsVisibleTo("TestSuiteAssembly")]

Ответ 2

Вы могли бы просто наследовать класс unit test наследовать от сеанса (при условии, что ваша тестовая среда не требует, чтобы вы наследовали определенный класс). Например, с помощью NUnit:

[TestFixture]
public class SessionTest : Session
{
    public SessionTest()
        : base() // call protected constructor
    {
    }

    [Test]
    public void TestSomething()
    {
    }

}

Ответ 3

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

public class TestSession : Session
{

   public TestSession() : base()
   {

   }

}

Ответ 4

Вы хотите использовать такой продукт, как TypeMock, который позволит вам создавать издеваемые (поддельные) экземпляры классов, например

var myInstance = Isolate.Fake.Instance<Session>();
// mock behavior here
// do assertions here

Вы можете создавать экземпляры абстрактных классов с помощью TypeMock, а также для записи.

Ответ 5

Я бы поставил под вопрос значение создания внутреннего конструктора класса сеанса.

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

Ответ 6

Если вы можете выйти с конструктором "protected internal", то, предполагая, что ваши тесты находятся в другой сборке, вы можете добавить атрибут InternalsVisibleTo к своей "готовой к тестированию сборке". Это позволит вашим тестам видеть внутренние члены тестируемой сборки ".

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