Meine Frage mag für einige von euch sehr dumm sein, aber ich muss fragen .. Entschuldigung ..
Ich verstehe Prinzipien der Komponententests nicht wirklich. Wie können Sie Klassen Ihrer Business-Klassen oder Datenzugriffsebene testen, ohne Ihre Datenbank zu ändern? Ich erkläre, ich habe eine Funktionalität, die ein Feld in einer Datenbank aktualisieren .. Nichts so erstaunlich .. Die Business-Schicht-Klasse wird instanziiert und die Methode BLL.Update () macht einige Kontrollen und schließlich instanziieren eine DAL-Klasse, die eine gespeicherte Prozedur in der Datenbank mit den richtigen Parametern starten.
Es funktioniert, aber meine Frage ist ..
Um Komponententests zu machen, die die DALayerklasse testen, muss ich die Datenbank in den Tests beeinflussen! Um beispielsweise zu testen, ob der Wert 5 an die DataBase übergeben wurde, muss ich das tun und das Datenbankfeld wird nach dem Test 5 sein!
So weiß ich normalerweise, dass das System nicht durch Tests beeinflusst wird, also verstehe ich nicht, wie man Tests ohne execute Methoden durchführen kann.
Tx für Antworten und entschuldige mein armes Englisch ..
Ich werde Ihre Frage in mehrere Unterfragen aufteilen, weil es schwierig ist, sie gemeinsam zu beantworten.
Komponententest x Integrationstest
Wenn Sie Komponententest schreiben, testen Sie eine einfache Einheit. Das bedeutet, dass Sie den einzelnen Ausführungspfad in der getesteten Methode testen. Sie müssen es vermeiden, Abhängigkeiten wie die erwähnte Datenbank zu testen. Üblicherweise schreiben Sie für jeden Ausführungspfad einen einfachen Komponententest, so dass Sie von Ihren Tests eine gute Codeabdeckung erhalten.
Wenn Sie den Integrationstest schreiben, testen Sie alle Schichten, um zu sehen, ob Integration und Konfiguration funktionieren. Normalerweise schreiben Sie keinen Integrationstest für jeden Ausführungspfad, da es zu viele Kombinationen über alle Ebenen gibt.
Testen von Geschäftsklassen - Komponententests
Sie müssen Ihre Business-Klassen ohne Abhängigkeit von DAL und DB testen. Um dies zu tun, müssen Sie Ihre BL-Klasse so entwerfen, dass diese Abhängigkeiten von außen injiziert werden. Zuerst müssen Sie eine abstrakte Klasse oder Schnittstelle für DAL definieren und diese DAL-Schnittstelle als Parameter an den Konstruktor übergeben (eine andere Möglichkeit besteht darin, die setzbare Eigenschaft für die BL-Klasse verfügbar zu machen). Wenn Sie Ihre BL-Klasse testen, verwenden Sie eine andere Implementierung der DAL-Schnittstelle, die nicht von der DB abhängig ist. Es gibt bekannte Testmuster Mock, Stub und Fake, die definieren, wie diese Dummy-Implementierungen erstellt und verwendet werden. Mocking wird auch von vielen Test-Frameworks unterstützt.
Testen der Datenzugriffsebene - Integrationstest
Sie müssen Ihre DAL gegen echte DB testen. Sie bereiten eine Test-DB mit Testdatensätzen vor und Sie schreiben Ihre Tests, um mit diesen Daten zu arbeiten. Jeder Test wird in einer eigenen Transaktion ausgeführt, die am Ende zurückgesetzt wird, damit der ursprüngliche Datensatz nicht geändert wird.
Beste Grüße, Ladislav
Für das Szenario, das Sie in Bezug auf db-Interaktion beschreiben, ist Mocking nützlich. Wenn Sie eine Chance haben, werfen Sie einen Blick auf Rhino Mocks
Sie verwenden Inversion der Kontrolle zusammen mit einem spöttischen Framework, z. Rhino Mocks als jemand bereits erwähnt
Wenn Sie nicht versuchen, im Test zu spotten und die tatsächliche DB zu verwenden, dann wird es Integrationstests in Laienform sein und es ist kein Unit-Test mehr. Ich arbeitete an einem Projekt, in dem eine dedizierte sql .mdf in der Quellcodeverwaltung war, die mit NUnit im [Setup] Teil von [SetupFixture] an den Datenbankserver angehängt wurde, ähnlich wie in [TearDown]. Dies wurde jedes Mal durchgeführt, wenn ein NUnit-Test durchgeführt wurde. Je nach SQL-Code und der Größe der Daten kann dies sehr zeitaufwändig sein.
Jetzt ist der Catch der Maintenance-Overhead, Sie können die Datenbank während des Sprint-Zyklus ändern und das Change-DB-Skript muss in allen Datenbanken ausgeführt werden, die für Ihre Entwicklung und Tests verwendet werden oben erwähnt. Nicht nur das, neue Testdaten (wie oben erwähnt) müssen für neue Tabellen / Spalten erstellt werden. Ebenso müssen die vorhandenen Daten aufgrund von Änderungen der Anforderungen oder Fehlerbehebungen gereinigt werden.
Dies scheint eine Aufgabe für sich zu sein, und jemand, der im Team kompetent ist, kann das Eigentum übernehmen oder wenn es die Zeit erlaubt, können Sie die Ausführung von Änderungsskripten als Teil von Continuous Integration integrieren, wenn Sie bereits eines implementiert haben. Dennoch muss das Hinzufügen und Bereinigen der Testdaten manuell durchgeführt werden.
Tags und Links c# unit-testing