Meine Anwendung

Ich habe ein Anwendungsdesign, das so aussieht:

web application layer - asp.net MVC-App mit Controllern und Ansichten, die POCOs verwenden und Dienste aufrufenServiceschicht - Geschäftsprozesse, die POCOs verwenden und Repositorys aufrufen Datenebene - Repositorys, die POCOs verwenden und mit dem Modell in Form eines EF-Modells kommunizieren, das Teil derselben Ebene ist.POCO-Schicht - Definiert alle Klassen, die für die Kommunikation zwischen diesen Schichten verwendet werden.

Also ist meine Datenschicht für die Implementierung des Datenmodells völlig transparent, da die obere Schicht überhaupt keine Datenentitäten verwendet.

Teste

oweit ich Unit-, Integrations- und Systemtests (in Bezug auf Asp.net MVC) verstehe, ist die

unit testing - das ist einfach. Verspotten Sie entkoppelte Objekte und injizieren Sie sie in Ihrem Unit-Test, damit das getestete Gerät sie verwendet.integrationstests - sollten eine Gruppe von Produktionsfunktionalitätseinheiten bilden und den Rest verspotten: Schreiben Sie daher Integrationstests, mit denen die Integration von Controllern, Diensten und Repositorys getestet werden kann, ohne die Produktionsdatenbank tatsächlich zu verwenden.system testing - Führe Tests auf allen Ebenen ohne Verspottung durch, was bedeutet, dass ich auch die Produktionsdatenbank (test) verwenden mussProble

Ich kann leicht sehen, wie Unit-Tests und Systemtests geschrieben werden, aber ich weiß nicht, wie Integrationstests geschrieben werden? Vielleicht ist meine Sicht auf diese völlig verzerrt und ich verstehe sie überhaupt nicht.

Wie sollte man Integration und Systemtests für eine Asp.net MVC-Anwendung schreiben?
Oder eine .net-Anwendung für diese Angelegenheit?

Einiger Code, der das Problem erklärt

Angenommen, ich habe Klassen wie:

TaskController ruft inTaskServiceTaskService ruft inTaskRepositoryTaskRepository EF-Daten intern bearbeiten

Also hier sind meine (abgekürzten) Klassen:

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
    }
    ...
}

Unit Test ist einfach und würde so aussehen:

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

    TaskController controller = new TaskController(mock.Object);

    // do the test
}

Aber wenn es um einen Integrationstest geht, wie mache ich mich nur über bestimmte Teile der Integration lustig.

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

Zunächst kann ich hier nicht einfach eine Datenbank verspotten? Ich könnte das Repository verspotten und trotzdem einen echten Service und Controller haben ...