Должен ли я макет рамочных классов

Question

Я пишу проект «зеленого поля» с использованием C # и .NET Framework 4, и так как мое последнее приложение преследовало недостаток тестов и не очень тестируемый дизайн, я решил избежать этой ошибки на этот раз.

У меня есть внешние зависимости для каждого класса в интерфейсах, которые вводятся в класс, и сейчас я пишу конкретные реализации.Хотя я не собираюсь начинать писать модульные тесты для тестирования кода в фреймворке, я обеспокоен тем, что если в способе, которым я вызываю класс фреймворка, есть ошибка, то у меня нет возможности ее протестировать.В качестве очень простого примера допустим, что я использовал SQLCommand (на самом деле я использую EF 4.1, но это всего лишь пример), и я забыл установить свойство подключения в команде.Моя идея состоит в том, что, если бы я смоделировал определенные классы каркаса, я мог бы протестировать эти соглашения с помощью имитации и избежать потенциального источника ошибок.Это также будет означать, что я имитирую определенные исключения из классов инфраструктуры, которые неудобно проверять, но они встречаются, например UnauthorizedAccessException, OutOfMemoryException и т. Д.

Я понимаю, что код, скорее всего, просто сломается, когда я попытаюсь запустить кодчтобы проверить это, но что-то в глубине души говорит мне, что есть шанс, что я могу что-то упустить и узнать об этом только после того, как продукт появится в продаже.Есть ли основания для этого или это довольно серьезный случай ЯГНИ?

Answer 1

Создание конкретных макетов Injected Interfaces заходит слишком далеко.Вам не нужно подражать всей структуре.Однако вам следует проверять пути к коду и убедиться, что вы правильно обрабатываете исключения и недопустимые входные данные.

Большинство фальшивых фреймворков, таких как Rhino Mocks, позволяют имитировать выбросы исключений из внедренных фиктивных объектов.

[Test]
public void testThrowsExceptions()
{
    // Arrange
    var dependency1 = MockRepository.Mock<IMockFrameworkObject1>();
    var dependency2 = MockRepository.Mock<IMockFrameworkObject2>();

    dependency2.Expect(d2 => d2.SomeAction).Throws(new someexception);

    var myObject = new ConcreteObject(dependency1, dependency2);

    // Act
    myObject.SomeAction();

    // Assert
}

Answer 2

Вы можете использовать Молей для имитации вызовов метода фреймворка. Вот как это используется для базы данных: Использование Mole для модульного тестирования SQLDataReader

Answer 3

Я вижу значительную ценность в классах насмешек, чтобы можно было вводить трудно стимулируемые ошибки и, следовательно, правильно проверять ваши пути ошибок.

Я не вижу, как насмешливая структура может поймать "забыли"установить ххх "ошибка.Ваш Mock должен был бы «знать», что фреймворк ожидает вызова setConnection () перед findThing (), чтобы перехватить те ошибки, которые вам понадобятся для эмуляции всей фреймворка.

Я думаю, что вам нужнопосмотрите на модульное тестирование - используйте свои собственные пути к коду - что может быть полезно при использовании тестов Mocks и Integration, которые тестируют взаимодействие различных компонентов, таких как ваш код с фреймворком.

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