Wie testet man Code, der Linq to SQL verwendet?

StackOverflow https://stackoverflow.com/questions/52657

  •  09-06-2019
  •  | 
  •  

Frage

Wie testet man Unit-Code, der Linq to SQL verwendet?

War es hilfreich?

Lösung

Aktualisieren:

Fredrik hat in seinem Blog eine Beispiellösung für Unit-Tests von linq2sql-Anwendungen veröffentlicht.Sie können es herunterladen unter:

http://web.archive.org/web/20120415022448/http://irideszenz.no/post/DataContext-Repository-Pattern-Example-Code.aspx

Ich finde es nicht nur großartig, dass er eine Beispiellösung veröffentlicht hat, er hat es auch geschafft, Schnittstellen für alle Klassen zu extrahieren, was das Design entkoppelter macht.

Mein alter Beitrag:

*Ich habe diese Blogs gefunden, die meiner Meinung nach ein guter Anfang für die Erstellung des DataContext-Wrappers sind:Link1 Link2

Sie decken fast das gleiche Thema ab, außer dass die erste auch Mittel zum Extrahieren von Schnittstellen für die Tabellen implementiert.Da der zweite jedoch umfangreicher ist, habe ich ihn ebenfalls eingefügt.*

Andere Tipps

3 Jahre zu spät, aber so mache ich es:

https://github.com/lukesampson/LinqToSQL-test-extensions/

Sie müssen keinen Wrapper schreiben oder viele Klempnerarbeiten durchführen. Legen Sie einfach die T4-Vorlage neben Ihre .dbml-Datei und Sie erhalten:

  1. Eine Schnittstelle für Ihren Datenkontext, z.B.IExampleDataContext
  2. Ein In-Memory-Mock für Ihren Datenkontext, z. B.MemoryExampleDataContext

Beide verwenden automatisch die Zuordnungen, die Sie bereits in Ihrer DBML konfiguriert haben.

So können Sie Dinge tun wie

public class ProductRepo {
    IExampleDataContext DB { get; set };
    public ProductRepo(IExampleDataContext db) {
        DB = db;
    }

    public List<Product> GetProducts() {
        return DB.Products.ToList();
    }
}

und Sie können das mit beiden aufrufen

new ProductRepo(new MemoryExampleDataContext()).GetProducts(); // for testing

oder

new ProductRepo(new ExampleDataContext()).GetProducts(); // use the real DB

Wickeln Sie den DataContext ein und verspotten Sie dann den Wrapper.Dies ist der schnellste Weg, dies zu erreichen, auch wenn zum Testen Programmieren erforderlich ist, was manche Leute für übel halten.Aber manchmal, wenn es Abhängigkeiten gibt, die nicht (einfach) verspottet werden können, ist das der einzige Weg.

Linq macht das Testen viel einfacher.Linq-Abfragen funktionieren bei Listen genauso gut wie bei Linq-zu-SQL-Inhalten.Sie können Linq gegen SQL für Listenobjekte austauschen und auf diese Weise testen.

Mattwar drüben bei Das Wayward Web Log Ich hatte einen großartigen Artikel darüber, wie man einen erweiterbaren Linq2Sql-Datenkontext modelliert.Hör zu -- MOCKS NIX – EIN ERWEITERBARER LINQ TO SQL DATACONTEXT

Normalerweise müssen Sie den Teil des Codes, der LINQ to SQL verwendet, nicht testen, aber wenn Sie es wirklich möchten, können Sie dieselben Datensätze verwenden, die Sie beim Server abfragen, und sie in speicherinterne Objekte umwandeln Führen Sie die LINQ-Abfragen dagegen aus (wobei die Enumerable-Methoden anstelle von Queryable verwendet würden).

Eine andere Möglichkeit ist die Verwendung von Matt Warren verspottebare Version des DataContext.

Sie können die von LINQ to SQL verwendeten SQL-Anweisungen auch abrufen, indem Sie sie über den Debugger (vom IQueryable-Objekt) abrufen, diese manuell überprüfen und sie dann in die automatisierten Tests einbeziehen.

LINQ to SQL eignet sich tatsächlich sehr gut für Komponententests, da es die Möglichkeit bietet, Datenbanken im Handumdrehen aus dem zu erstellen, was in Ihrer DBML definiert ist.

Es macht es wirklich angenehm, eine ORM-Ebene zu testen, indem man die Datenbank über den DataContext erstellt und sie zunächst leer hat.

Ich beschreibe es hier in meinem Blog: http://web.archive.org/web/20090526231317/http://www.aaron-powell.com/blog/may-2008/unit-testing-linq-to-sql.aspx

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