Как писать интеграционные и системные тесты в Asp.net MVC

Question

Мое заявление

У меня есть дизайн приложения, который выглядит следующим образом:

• Уровень веб-приложения — приложение asp.net MVC с контроллерами и представлениями, которые используют POCO и службы вызовов.
• уровень обслуживания — бизнес-процессы, использующие POCO и репозитории вызовов.
• уровень данных — репозитории, которые используют POCO и взаимодействуют с моделью в форме модели EF, которая является частью этого же уровня.
• Уровень POCO — определяет все классы, которые используются для взаимодействия между этими уровнями.

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

Тестирование

Насколько я понимаю модульное, интеграционное и системное тестирование (применительно к Asp.net MVC), это:

• модульное тестирование — это легко.Смоделируйте разделенные объекты и внедрите их в свой модульный тест, чтобы тестируемый модуль использовал их.
• интеграционное тестирование — следует составить группу модулей производственного функционала и издеваться над остальными:поэтому написание интеграционных тестов, которые будут проверять интеграцию контроллера, сервиса и репозитория без фактического использования производственной базы данных.
• тестирование системы — запускайте тесты на всех уровнях без каких-либо издевательств, то есть мне также придется использовать производственную (тестовую) базу данных

Проблема

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

Как писать интеграционные и системные тесты для приложения Asp.net MVC?
Или любое .net-приложение в этом отношении?

Некоторый код, который помогает объяснить проблему

Предположим, у меня есть такие классы, как:

• TaskController звонит в TaskService
• TaskService звонит в TaskRepository
• TaskRepository манипулировать данными EF внутри

Итак, вот мои (сокращенные) классы:

public class TaskController
{
    private ITaskService service;

    // injection constructor
    public TaskController(ITaskService service)
    {
        this.service = service;
    }

    // default constructor
    public TaskController() : this(new TaskService()) {}

    public ActionResult GetTasks()
    {
        return View(this.service.GetTasks());
    }
    ...
}

public class TaskService : ITaskService
{
    private ITaskRepository repository;

    // injection constructor
    public TaskService(ITaskRepository repository)
    {
        this.repository = repository;
    }

    // default constructor
    public TaskService() : this(new TaskRepository()) {}

    public IList<Task> GetTasks()
    {
        return this.repository.GetTasks();
    }
    ...
}

public class TaskRepository : ITaskRepository
{
    public IList<Task> GetTasks()
    {
        // code that gets tasks from EF and converts to Task POCOs
    }
    ...
}

Юнит-тест прост и будет выглядеть так:

public void UnitTest()
{
    var mock = new Mock<ITaskService>();
    // other code that mocks the service

    TaskController controller = new TaskController(mock.Object);

    // do the test
}

Но когда дело доходит до интеграционного теста, как мне имитировать только определенные части интеграции?

public void IntegrationTest()
{
    // no mocking at all
    TaskController = new TaskController();
    // do some testing
}

Прежде всего, я не могу здесь просто издеваться над базой данных?Хотя я мог бы издеваться над репозиторием и иметь настоящий сервис и контроллер...

Answer 1

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

Для меня системное тестирование — это функциональное тестирование (еще один уровень тестирования с использованием чего-то вроде Fit) или тестирование пользовательского интерфейса с помощью такого инструмента, как testcomplete или инструмент QA от Telerik.

ХТХ.

Answer 2

Тесты интеграции, которые не включают в себя UI, все еще могут быть написаны в NUNIT, XUNIT и т. Д.

Для ASP.NET MVC в частности (или любое веб-приложение) вы можете использовать Утомитель или Селен Чтобы написать тесты системы / интеграции с использованием пользовательского интерфейса.

Вы могли бы также захотеть посмотреть на Тст Для тестирования блока T-SQL и Спецификация Если вам интересно о BDD в .NET.

Примечание. Я написал это до обновления вопроса с кодом и описанием конкретной ситуации. Это на самом деле больше не решает вопрос, но, надеюсь, все равно будет интересным / полезным для кого-то.

Answer 3

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

Часть этого вопроса состоит в том, что тесты на более высокий уровень интеграции становятся слишком сложными v. Быстро. Это природа проблемы, поэтому я предпочитаю убедиться, что все отдельные детали работают как предназначенные, через модульные тесты и сфокусированные тесты интеграции в зависимости от участия в классе.

С вышеупомянутым на месте вам нужно только убедиться, что отдельные фигуры правильно подключены, поэтому я использую полные системные тесты для этого. Это лучшее из его эффекта, если код следует солидно и высохнуть.