Как настроить интеграционные тесты на сервисном уровне приложения: с помощью команд сервисного уровня или напрямую с помощью домена? - PullRequest
Новая
       6

Как настроить интеграционные тесты на сервисном уровне приложения: с помощью команд сервисного уровня или напрямую с помощью домена?

0 голосов
/ 29 июля 2011

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

[TestFixture]
public class IntegrationTests
{
    [Test]
    public void CreateOrder()
    {
        new OrderService().Execute(new CreateOrderCommand());

        // check some assertions on a retrieved viewmodel
    }

    [Test]
    public void AddItemToOrder()
    {
        var service = new OrderService();
        var orderId = service.Execute(new CreateOrderCommand());
        service.Execute(new AddItemToOrderCommand(orderId, "itemcode"));

        // check some assertions on the viewmodel
    }

    [Test]
    public void SubmitOrder()
    {
        var service = new OrderService();
        var orderId = service.Execute(new CreateOrderCommand());
        service.Execute(new AddItemToOrderCommand(orderId, "itemcode"));
        service.Execute(new SubmitOrderCommand(orderId));

        // check some assertions on the viewmodel
    }
}

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

Одной из альтернатив является создание объекта домена непосредственно в том состоянии, в котором я его хочу, например ::

new Order(OrderStatus.Unsubmitted, new OrderItem("itemcode"))

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

Какой подход я должен использовать, чтобы убедиться, что мои интеграционные тесты выполняют свою полезную функцию, оставаясь при этом обслуживаемыми?

...