Unit-Tests mit Datenzugriffsschicht

Question

Was ist eine gute Möglichkeit, Unit-Tests mit einem LINQ-to-SQL-DAL zu schreiben?

Derzeit führe ich einige Datenbanktests durch und muss Hilfsmethoden erstellen, die auf die Datenbank zugreifen, aber ich möchte diese Methoden nicht in meinem Haupt-Repository haben.

Also habe ich zwei Kopien des DAL, eine in meinem Hauptprojekt und eine im Testprojekt. Ist es einfacher, diese Dinge zu verwalten, wenn ich ein separates Projekt für die Datenschicht erstelle? Ich bin mir nicht sicher, welcher Ansatz besser ist.

Wenn ich ein Datenschichtprojekt erstelle, würde ich dann auch alle meine Repositorys in dieses Projekt verschieben? Ich bin mir nicht sicher, wie ich die Schichten richtig einrichten soll.

Danke

Answer 1

Ich würde das im September 2009 im Visual Studio Magazin beschriebene Repository-Pattern verwenden, das in dem Artikel "Beseitigung von Datenbankabhängigkeiten in der testgesteuerten Entwicklung" vorgestellt wurde. Seitdem ich den Artikel gelesen habe, habe ich dieses Muster mit großem Erfolg verwendet. Dieses Muster hilft dabei, Ihre Datenschicht zu entkoppeln und gute Unittests zu schreiben.

Das wird erfordern, dass Sie eine mehrschichtige Architektur übernehmen und eine separate Datenschicht erstellen, aber auf lange Sicht lohnt es sich.

Hier ist ein Link zum Online-Artikel. Repository Pattern

Answer 2

Ich verwende Linq2Sql für meine DAL-Schicht und habe sie als separates Projekt. In meinem Domain-Projekt habe ich eine Repository-Schnittstelle, die ich dann mit einem benutzerdefinierten Linq2SqlCarRepository in meinem DAL-Projekt implementiere. Diese Klasse kapselt die generierten Linq2Sql-Klassen.

z. B. Im Car.Core-Projekt

 public interface ICarRepository
 {
    IQueryable GetAllCars();
    void Add(Car);
 }

Dann habe ich eine Implementierung der Schnittstelle, die den Zugriff auf die generierte Linq2Sql-Klasse kapselt.

Car.Data-Projekt

public class SqlCarRepository : ICarRepository
{
    private CarDataContext _context;

    public SqlCarRepository()
    {
        _context = new CarDataContext();
    }

    #region ICarRepository Members

    public IQueryable GetAllCars()
    {
        return _context.Cars;
    }

Dann habe ich ein Testprojekt Car.Data.Test, das Mocks verwendet, um das ICarRepository zu mocken und zu testen. Ich denke, das ist etwas anders als das, was du beschreibst. Aber ich denke, du möchtest versuchen, deine DAL von deiner Anwendung zu trennen, damit sie peripher ist und bei Bedarf ausgetauscht werden kann.

Ich habe noch nicht alles komplett sortiert, aber ich habe derzeit diese Projekte:

Car.Core         --- Alle Schnittstellen und Domänenobjekte, DTOs usw.
Car.Core.Tests   --- Die Tests der Kerngeschäftslogik.
Car.Web          --- Asp.net MVC Frontend
Car.Web.Tests    --- Tests für die Website
Car.Data         --- Hier befinden sich die Linq2Sql-Dinge
Car.Data.Tests   --- Die Tests für die DAL-Schicht

Das ist das, was ich derzeit habe, obwohl es vielleicht nicht der beste Weg ist, die Dinge jetzt zu tun.

Ich empfehle, The Onion Architecture durchzulesen und die MVC StoreFront -Videos zur Inspiration anzusehen; viel Glück.