2010-05-05 1 views
13

Was ist eine gute Möglichkeit, Komponententests mit LINQ to SQL DAL zu schreiben?Komponententest mit Datenzugriffsschicht

Zurzeit mache ich einige Datenbank-Tests und muss Hilfsmethoden erstellen, die auf die Datenbank zugreifen, aber ich möchte diese Methoden nicht in meinen Hauptrepo's.

Also was ich habe, ist zwei Kopien der DAL, eins in meinem Hauptprojekt und eins 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 Weg ein besserer Ansatz ist.

Wenn ich ein Datenschichtprojekt erstelle, würde ich auch alle meine Repos in dieses Projekt verschieben? Ich bin mir nicht sicher, wie man die Schichten richtig einrichtet.

Dank

+0

Ich lese die "Wenn ich eine Datenschicht Projekt erstellen würde ich alle meine Repos zu diesem Projekt auch verschieben?" Frage wie Sie bereits verwenden das Repository-Muster in den Antworten vorgeschlagen, aber offenbar müssen Sie auch eine Art von Datenbankzugriff, in einigen Ihrer Tests zu tun? Normalerweise würde dies bedeuten, dass Sie Linq zu SQL testen, was ich von Microsofts Ingenieuren bereits erwartet hätte.Ich würde Ihnen empfehlen, diese Methoden zu vermeiden und Ihre Repositories mit einem Speicherkontext-Backend zu testen, wie in dem Artikel beschrieben, auf den Jason Jones verweist. – AHM

Antwort

5

I Linq2Sql für meine DAL Schicht, und ich habe es als ein separates Projekt bin mit. In meinem Domain-Projekt habe ich eine Repository-Schnittstelle, die ich dann mit einem eigenen Linq2SqlCarRepository in meinem DAL-Projekt implementiere, diese Klasse wickelt die generierten Linq2Sql-Klassen auf.

z. In Car.Core Projekt

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

Ich habe dann eine Implementierung der Schnittstelle, die den Zugriff auf die erzeugte Linq2Sql Klasse einpackt.

Car.Data Projekt

public class SqlCarRepository : ICarRepository 
{ 
    private CarDataContext _context; 

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

    #region ICarRepository Members 

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

Ich habe dann ein Testprojekt Car.Data.Test die dann Mocks verwendet die ICarRepository und Tests weg zu verspotten. Ich denke, das ist etwas anders als das, was Sie beschreiben. Aber ich denke, du willst versuchen, DAL von deiner Anwendung zu trennen, damit es ein Peripheriegerät ist, das du austauschen kannst, wenn du willst.

Ich habe keine ganze vollständig sortiert, aber ich habe gerade diese Projekte:

Car.Core   --- All the interfaces and domain objects, DTO's etc 
Car.Core.Tests --- The tests of the core business logic. 
Car.Web   --- Asp.net MVC frontend 
Car.Web.Tests --- Tests for the website 
Car.Data   --- The Linq2Sql stuff lives in here 
Car.Data.Tests --- The tests for the DAL layer 

Das ist, was ich zur Zeit habe, obwohl es nicht der beste Weg, die Dinge könnten jetzt zu tun.

Ich würde empfehlen, The Onion Architecture zu lesen und die MVC StoreFront Videos für Inspiration betrachten; Viel Glück.

6

Ich würde das Repository-Muster verwenden, das im September 2009 im Visual Studio-Magazin mit dem Titel "Eliminate Database Dependencies in Test-Driven Entwicklung" beschrieben wurde. Ich benutze dieses Muster, seit ich den Artikel mit großem Erfolg gelesen habe. Dieses Muster hilft Ihnen, Ihre Datenschicht zu entkoppeln und gute Komponententests zu schreiben.

Dazu müssen Sie eine n-Tier-Architektur übernehmen und eine separate Datenschicht erstellen, aber auf lange Sicht ist es das wert.

Hier ist ein Link zum Online-Artikel. Repository Pattern