Frage

Meine Anwendung

Ich habe eine Anwendung Design, das aussieht wie folgt:

  • Web Application Layer - asp.net MVC-app mit Controllern und Views, dass die Verwendung POCOs und Anrufdienste
  • Service-Layer - Geschäftsprozesse, dass die Verwendung POCOs und Call-Repositories
  • Datenschicht - Repositories, die Verwendung POCOs und kommuniziert mit dem Muster in Form von EF-Modell, das Teil dieser gleichen Schicht ist
  • POCO Schicht - definiert alle Klassen, die für die inter Kommunikation zwischen diesen Schichten verwendet werden

Also meine Datenschicht ist völlig transparent für Datenmodell Implementierung, da obere Schicht Dateneinheiten überhaupt nicht verwenden.

Testing

So viel wie ich verstehe, Einheit, Integrations- und Systemtests (mit Bezug auf Asp.net MVC) ist dies:

  • Unit-Tests - dies ist einfach. Mock entkoppelt Objekte und spritzen sie in Ihrem Gerät zu testen, so geprüfte Einheit, sie wird mit
  • Integrationstests - sollten eine Gruppe von Produktionseinheiten Funktionalität machen und den Rest verspotten: so das Schreiben Integrationstests, die Steuerung, Service und Repository-Integration, ohne tatsächlich mit Produktionsdatenbank
  • testen würde
  • Systemtests - durchgeführten Tests auf allen Ebenen ohne spöttisch, was bedeutet, ich Gebrauch Produktion haben (Test) Datenbank und

Problem

Ich kann leicht sehen, wie Unit-Tests sowie Systemtests zu schreiben, aber ich weiß nicht, wie Integrationstests zu schreiben? Vielleicht ist meine Sicht auf diesen völlig verzerrt und ich weiß nicht, sie überhaupt verstehen.

Wie sollte einen Schreib Integrations- und Systemtests für eine Asp.net MVC-Anwendung?
Oder jede .net-Anwendung für diese Angelegenheit?

Einige Code, der das Problem

hilft erklären,

Angenommen, ich habe Klassen wie:

  • TaskController Anrufe in TaskService
  • TaskService Anrufe in TaskRepository
  • TaskRepository manipulieren EF Daten intern

So, hier sind meine (abgekürzt) 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 wie folgt 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 kommt, wie verspotten ich nur bestimmte Teile der Integration.

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

Zunächst einmal kann ich nicht nur Mock-Datenbank hier? Ich konnte Repository verspotten und haben echten Service und Controller obwohl ...

War es hilfreich?

Lösung

Integrationstests sollten die Integration zwischen den Komponenten testen. Während Komponententests Einzelstücke aus einer einzigen Komponente zu testen, testet Integration die Wechselwirkungen zwischen den Komponenten, und soll Live arbeiten. So ein Integrationstest eine Datenbank und alle anderen externen Abhängigkeiten nutzen würde, wo seine besten diese Dienste in Unit-Tests verspotten.

Systemtest mir Funktionsprüfung wäre (eine andere Ebene der Prüfung etwas wie fit verwendet wird), oder ui Prüfung durch ein Werkzeug wie Testcomplete oder telerik QA-Tool.

HTH.

Andere Tipps

Integrationstests, die noch nicht über die Benutzeroberfläche betreffen können in NUnit, xUnit geschrieben werden, etc.

Für ASP.NET MVC insbesondere (oder eine Web-Anwendung), können Sie WatiN oder Selenium Schreibsystem / Integrationstests der Benutzeroberfläche verwendet wird.

Sie möchten vielleicht auch sehen TST für T-SQL-Unit-Tests und SpecFlow , wenn Sie in .NET neugierig auf BDD sind.

Hinweis: Ich schrieb dies vor der Frage mit Code und einer Beschreibung der spezifischen Situation aktualisiert wurde. Es ist nicht wirklich die Frage Adresse mehr, aber hoffentlich wird noch interessant / nützlich für jemanden sein.

Ich antwortete nur auf eine ähnliche Frage: Integrationstests Implementierung . Ich denke, es ist das Problem angesprochen, indem ein klares Konzept präsentieren zu nehmen.

Ein Teil des Problems ist, dass eine höhere Ebene Integrationstests zu komplex v erhalten. Schnell. Es ist die Art des Problems, so ziehe ich sicher, ob die separaten Stücke wie vorgesehen, durch Unit-Tests zu machen und konzentrierten Tests Integration von der Klasse abhängig beteiligt.

Mit dem oben im Ort, Sie müssen sicherstellen, dass die einzelnen Stücke richtig süchtig sind, so dass ich die vollen Systemtests dafür. Dies hat den besten seiner Wirkung, wenn der Code fest und trocken folgt.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top