Database
 sql >> Datenbank >  >> RDS >> Database

Die Kunst, Abhängigkeiten und Daten beim Testen von Datenbankeinheiten zu isolieren

Alle Datenbankentwickler schreiben mehr oder weniger Datenbank-Einheitentests, die nicht nur dabei helfen, Fehler frühzeitig zu erkennen, sondern auch viel Zeit und Mühe sparen, wenn das unerwartete Verhalten von Datenbankobjekten zu einem Produktionsproblem wird.

Heutzutage gibt es eine Reihe von Datenbank-Unit-Testing-Frameworks wie tSQLt zusammen mit Unit-Testing-Tools von Drittanbietern, einschließlich dbForge Unit Test.

Einerseits besteht der Vorteil der Verwendung von Testtools von Drittanbietern darin, dass das Entwicklungsteam sofort Unit-Tests mit zusätzlichen Funktionen erstellen und ausführen kann. Außerdem gibt Ihnen die direkte Verwendung eines Testframeworks mehr Kontrolle über die Komponententests. Daher können Sie dem Unit-Testing-Framework selbst weitere Funktionen hinzufügen. In diesem Fall muss Ihr Team jedoch Zeit und ein gewisses Maß an Fachwissen haben, um dies zu tun.

In diesem Artikel werden einige Standardpraktiken untersucht, die uns helfen können, die Art und Weise zu verbessern, wie wir Datenbankkomponententests schreiben.

Lassen Sie uns zunächst einige Schlüsselkonzepte des Datenbank-Unit-Tests durchgehen.

Was ist Database Unit Testing

Laut Dave Green stellen Datenbankkomponententests sicher, dass kleine Einheiten der Datenbank wie Tabellen, Ansichten, gespeicherte Prozeduren usw. wie erwartet funktionieren.

Datenbankkomponententests werden geschrieben, um zu überprüfen, ob der Code die Geschäftsanforderungen erfüllt.

Wenn Sie beispielsweise eine Anforderung wie „Ein Bibliothekar (Endbenutzer) sollte in der Lage sein, neue Bücher zur Bibliothek hinzuzufügen (Verwaltungsinformationssystem)“ erhalten, müssen Sie daran denken, Einheitentests für die gespeicherte Prozedur anzuwenden, um dies zu überprüfen es kann ein neues Buch zum Buch hinzufügen Tabelle.

Manchmal stellt eine Reihe von Unit-Tests sicher, dass der Code die Anforderungen erfüllt. Daher ermöglichen die meisten Komponententest-Frameworks, einschließlich tSQLt, das Gruppieren verwandter Komponententests in einer einzigen Testklasse, anstatt einzelne Tests auszuführen.

AAA-Prinzip

Erwähnenswert ist das 3-Stufen-Prinzip des Unit-Tests, das eine gängige Praxis beim Schreiben von Unit-Tests ist. Das AAA-Prinzip ist die Grundlage für Unit-Tests und besteht aus den folgenden Schritten:

  1. Anordnen/Zusammenbauen
  2. Handeln
  3. Bestätigen

Das Anordnen Abschnitt ist der erste Schritt beim Schreiben von Komponententests für Datenbanken. Es führt durch die Konfiguration eines Datenbankobjekts zum Testen und Einrichten der erwarteten Ergebnisse.

Das Gesetz -Abschnitt ist, wenn ein Datenbankobjekt (im Test) aufgerufen wird, um die eigentliche Ausgabe zu erzeugen.

Die Assert Schritt befasst sich mit dem Abgleich der tatsächlichen Ausgabe mit der erwarteten und überprüft, ob der Test bestanden wird oder fehlschlägt.

Lassen Sie uns diese Methoden an bestimmten Beispielen untersuchen.

Wenn wir einen Komponententest erstellen, um zu überprüfen, ob die AddProduct gespeicherte Prozedur ein neues Produkt hinzufügen kann, richten wir das Produkt ein und Erwartetes Produkt Tabellen, nachdem das Produkt hinzugefügt wurde. In diesem Fall kommt die Methode in den Abschnitt Arrange/Assemble.

Das Aufrufen der AddProduct-Prozedur und das Einfügen des Ergebnisses in die Product-Tabelle wird im Act-Abschnitt behandelt.

Der Assert-Teil gleicht einfach die Product-Tabelle mit der ExpectedProduct-Tabelle ab, um zu sehen, ob die gespeicherte Prozedur erfolgreich ausgeführt wurde oder fehlgeschlagen ist.

Abhängigkeiten beim Unit-Test verstehen

Bisher haben wir die Grundlagen des Datenbank-Unit-Tests und die Bedeutung des AAA-Prinzips (Assemble, Act, and Assert) bei der Erstellung eines Standard-Unit-Tests besprochen.

Konzentrieren wir uns nun auf ein weiteres wichtiges Teil des Puzzles – Abhängigkeiten beim Komponententest.

Abgesehen davon, dass wir dem AAA-Prinzip folgen und uns nur auf ein bestimmtes Datenbankobjekt (im Test) konzentrieren, müssen wir auch die Abhängigkeiten kennen, die sich auf Unit-Tests auswirken können.

Abhängigkeiten lassen sich am besten anhand eines Beispiels für einen Komponententest verstehen.

EmployeesSample Database Setup

Um fortzufahren, erstellen Sie eine Beispieldatenbank und nennen Sie sie EmployeesSample :

-- Erstellen Sie die Beispieldatenbank "Employees", um Komponententests zu demonstrieren. CREATE DATABASE EmployeesSample;GO

Erstellen Sie nun den Mitarbeiter Tabelle in der Beispieldatenbank:

-- Erstellen Sie die Employee-Tabelle in der BeispieldatenbankUSE EmployeesSampleCREATE TABLE Employee (EmployeeId INT PRIMARY KEY IDENTITY(1,1), NAME VARCHAR(40), StartDate DATETIME2, Title VARCHAR(50) ); 
Beispieldaten auffüllen
 

 Füllen Sie die Tabelle, indem Sie einige Datensätze hinzufügen:
 
-- Hinzufügen von Daten zur Employee-TabelleINSERT INTO Employee (NAME, StartDate, Title) VALUES ('Sam','2018-01-01', 'Developer'), ('Asif','2017-12-12 ','Tester'), ('Andy','2016-10-01','Senior Developer'), ('Peter','2017-11-01','Infrastructure Engineer'), ('Sadaf', '2015-01-01','Business Analyst');GO
 

 Die Tabelle sieht folgendermaßen aus:
 
-- Sehen Sie sich die Employee-Tabelle an. SELECT e.EmployeeId ,e.NAME ,e.StartDate ,e.Title FROM Employee e;GO
 

 
 

 Bitte beachten Sie, dass ich in diesem Artikel dbForge Studio für SQL Server verwende. Daher kann das Aussehen der Ausgabe abweichen, wenn Sie denselben Code in SSMS (SQL Server Management Studio) ausführen. Es gibt keinen Unterschied, wenn es um Skripte und deren Ergebnisse geht.
 
Anforderung zum Hinzufügen eines neuen Mitarbeiters
 

 Wenn nun eine Anforderung zum Hinzufügen eines neuen Mitarbeiters eingegangen ist, können Sie die Anforderung am besten erfüllen, indem Sie eine gespeicherte Prozedur erstellen, die der Tabelle erfolgreich einen neuen Mitarbeiter hinzufügen kann.
 

 Erstellen Sie dazu die gespeicherte Prozedur AddEmployee wie folgt:
 
 – Gespeicherte Prozedur zum Hinzufügen eines neuen Mitarbeiters CREATE PROCEDURE AddEmployee @Name VARCHAR(40),@StartDate DATETIME2,@Title VARCHAR(50)ASBEGIN SET NOCOUNT ON INSERT INTO Employee (NAME, StartDate, Title) VALUES (@Name , @StartDate, @Title);END
 
Einheitentest, um zu überprüfen, ob die Anforderung erfüllt ist
 

 Wir werden einen Datenbankkomponententest schreiben, um zu überprüfen, ob die gespeicherte Prozedur AddEmployee die Anforderung zum Hinzufügen eines neuen Datensatzes zur Employee-Tabelle erfüllt.
 

 Konzentrieren wir uns darauf, die Unit-Test-Philosophie zu verstehen, indem wir einen Unit-Test-Code simulieren, anstatt einen Unit-Test mit einem Test-Framework oder einem Unit-Test-Tool eines Drittanbieters zu schreiben.
 
Einheitentest simulieren und AAA-Prinzip in SQL anwenden
 

 Als erstes müssen wir das AAA-Prinzip in SQL nachahmen, da wir kein Unit-Testing-Framework verwenden werden.
 

 Der Abschnitt Assemble wird angewendet, wenn die tatsächlichen und erwarteten Tabellen normalerweise zusammen mit der erwarteten Tabelle eingerichtet werden, die gefüllt wird. Wir können SQL-Variablen verwenden, um die erwartete Tabelle in diesem Schritt zu initialisieren.
 

 Der Act-Abschnitt wird verwendet, wenn die eigentliche gespeicherte Prozedur aufgerufen wird, um Daten in die eigentliche Tabelle einzufügen.
 

 Der Assert-Abschnitt ist, wenn die erwartete Tabelle mit der tatsächlichen Tabelle übereinstimmt. Das Simulieren des Assert-Teils ist etwas knifflig und kann durch die folgenden Schritte erreicht werden:
 
     
  • Zählen der gemeinsamen (übereinstimmenden) Zeilen zwischen zwei Tabellen, die 1 sein sollten (da die erwartete Tabelle nur einen Datensatz hat, der mit der tatsächlichen Tabelle übereinstimmen sollte)
    • 
 
  • Das Ausschließen der tatsächlichen Tabellendatensätze aus den erwarteten Tabellendatensätzen sollte 0 ergeben (wenn der Datensatz in der erwarteten Tabelle auch in der tatsächlichen Tabelle existiert, dann sollte das Ausschließen aller tatsächlichen Tabellendatensätze aus der erwarteten Tabelle 0 zurückgeben)
    •  

 

 Das SQL-Skript lautet wie folgt:
 

 [expand title="Code"]
 
 – Simulieren des Einheitentests zum Testen der gespeicherten Prozedur „AddEmployee“ CREATE PROCEDURE TestAddEmployeeASBEGIN – (1) Assemblieren – Neue Mitarbeiterdaten einrichten DECLARE @EmployeeId INT =6 ,@NAME VARCHAR(40) ='Adil' ,@StartDate DATETIME2 ='2018-03-01' ,@Title VARCHAR(50) ='Development Manager' -- Einrichten der erwarteten Tabelle CREATE TABLE #EmployeeExpected ( EmployeeId INT PRIMARY KEY IDENTITY (6, 1) -- die erwartete Tabelle EmployeeId sollte beginnen mit 6 -- da die aktuelle Tabelle bereits 5 Datensätze hat und -- die nächste EmployeeId in der aktuellen Tabelle ist 6 ,NAME VARCHAR(40) ,StartDate DATETIME2 ,Title VARCHAR(50) ); -- Fügen Sie die erwarteten Tabellendaten hinzu INSERT INTO #EmployeeExpected (NAME, StartDate, Title) VALUES (@NAME, @StartDate, @Title); -- (2) Act -- Rufen Sie AddEmployee auf, um neue Mitarbeiterdaten zur Employee-Tabelle hinzuzufügen. ActualAndExpectedTableCommonRecords INT =0 – wir gehen davon aus, dass erwartete und tatsächliche Tabellendatensätze nichts gemeinsam haben SET @ActualAndExpectedTableCommonRecords =(SELECT COUNT(*) FROM (SELECT e.EmployeeId ,e.NAME ,e.StartDate ,e.Title FROM Employee e INTERSECT SELECT ee.EmployeeId , ee.NAME , ee.StartDate , ee.Title FROM #EmployeeExpected ee) AS A) DECLARE @ExpectedTableExcluldingActualTable INT =1 – wir gehen davon aus, dass die erwartete Tabelle Datensätze enthält, die in der tatsächlichen Tabelle SET @ExpectedTableExcluldingActualTable nicht vorhanden sind =(SELECT COUNT(*) FROM (SELECT ee.EmployeeId ,ee.NAME ,ee.StartDate ,ee.Title FROM #EmployeeExpected ee EXCEPT SELECT e.EmployeeId ,e.NAME ,e.StartDate ,e.Title FROM Employee e) AS A) IF @ActualAndExpectedTableCommonRecords =1 AND @ExpectedTableExcluldingActualTable =0 PRINT '*** Test Passed! ***' ELSE PRINT '*** Test fehlgeschlagen! ***'ENDE
 

 [/expandieren]
 
Simulierten Einheitentest ausführen
 

 Nachdem die gespeicherte Prozedur erstellt wurde, führen Sie sie mit dem simulierten Komponententest aus:
 
-- Ausführen eines simulierten Komponententests zur Überprüfung der gespeicherten Prozedur AddEmployeeEXEC TestAddEmployee
 

 Die Ausgabe sieht wie folgt aus:
 

 
 

 Herzliche Glückwünsche! Der Datenbankkomponententest wurde bestanden.
 
Identifizieren von Problemen in Form von Abhängigkeiten im Einheitentest
 

 Können wir Fehler in dem von uns erstellten Komponententest erkennen, obwohl er erfolgreich geschrieben und ausgeführt wurde?
 

 Wenn wir uns das Unit-Test-Setup (den Assemble-Teil) genauer ansehen, hat die erwartete Tabelle eine unnötige Bindung mit der Identitätsspalte:
 

 
 

 Bevor wir einen Komponententest schreiben, haben wir bereits 5 Datensätze zur tatsächlichen (Employee)-Tabelle hinzugefügt. Daher beginnt beim Testaufbau die Identitätsspalte für die erwartete Tabelle mit 6. Dies bedeutet jedoch, dass wir immer erwarten, dass sich 5 Datensätze in der tatsächlichen Tabelle (Employee) befinden, um sie mit der erwarteten Tabelle (#EmployeeExpected) abzugleichen.
 

 Um zu verstehen, wie sich dies auf den Unit-Test auswirken kann, werfen wir jetzt einen Blick auf die aktuelle (Employee)-Tabelle:
 

 
 

 Fügen Sie der Employee-Tabelle einen weiteren Datensatz hinzu:
 
-- Hinzufügen eines neuen Datensatzes zur Employee-TabelleINSERT INTO Employee (NAME, StartDate, Title) VALUES ('Mark', '2018-02-01', 'Developer');
 

 Sehen Sie sich jetzt die Employee-Tabelle an:
 

 
 

 Löschen Sie EmpoyeeId 6 (Adil), damit der Komponententest mit seiner eigenen Version von EmployeeId 6 (Adil) und nicht mit dem zuvor gespeicherten Datensatz ausgeführt werden kann.
 
-- Löschen des zuvor erstellten EmployeeId:6 (Adil)-Datensatzes aus der Employee-TabelleDELETE FROM Employee WHERE EmployeeId=6
 

 
 

 Führen Sie den simulierten Komponententest aus und sehen Sie sich die Ergebnisse an:
 
-- Ausführen des simulierten Komponententests zur Überprüfung der gespeicherten Prozedur AddEmployeeEXEC TestAddEmployee
 

 
 

 Der Test ist dieses Mal fehlgeschlagen. Die Antwort liegt in der Ergebnismenge der Employee-Tabelle, wie unten gezeigt:
 

 
 

 Die oben erwähnte Mitarbeiter-ID-Bindung im Einheitentest funktioniert nicht, wenn wir den Einheitentest erneut ausführen, nachdem wir einen neuen Datensatz hinzugefügt und den zuvor hinzugefügten Mitarbeiterdatensatz gelöscht haben.
 

 Es gibt drei Arten von Abhängigkeiten im Test:
 
     
  1. Datenabhängigkeit
    2. 
 
  2. Schlüsselbeschränkungsabhängigkeit
    3. 
 
  3. Identitätsspaltenabhängigkeit
    4. 
 
 
Datenabhängigkeit
 

 Zunächst einmal hängt dieser Komponententest von Daten in der Datenbank ab. Laut Dave Green sind die Daten selbst eine Abhängigkeit, wenn es um die Unit-Testing-Datenbank geht.
 

 Das bedeutet, dass sich Ihr Datenbankkomponententest nicht auf die Daten in der Datenbank verlassen sollte. Beispielsweise sollte Ihr Komponententest die eigentlichen Daten enthalten, die in das Datenbankobjekt (Tabelle) eingefügt werden sollen, anstatt sich auf die bereits in der Datenbank vorhandenen Daten zu verlassen, die gelöscht oder geändert werden können.
 

 In unserem Fall ist die Tatsache, dass bereits fünf Datensätze in die eigentliche Employee-Tabelle eingefügt wurden, eine Datenabhängigkeit, die verhindert werden muss, da wir nicht gegen die Philosophie des Unit-Tests verstoßen sollten, die besagt, dass nur die Unit des Codes getestet wird.
 

 Mit anderen Worten, Testdaten sollten sich nicht auf die tatsächlichen Daten in der Datenbank stützen.
 

 
 
Schlüsselbeschränkungsabhängigkeit
 

 Eine weitere Abhängigkeit ist eine Schlüsseleinschränkungsabhängigkeit, was bedeutet, dass die Primärschlüsselspalte EmployeeId ebenfalls eine Abhängigkeit ist. Es muss verhindert werden, um einen guten Unit-Test zu schreiben. Es ist jedoch ein separater Komponententest erforderlich, um eine Primärschlüsseleinschränkung zu testen.
 

 Um beispielsweise die gespeicherte Prozedur AddEmployee zu testen, sollte der Primärschlüssel der Employee-Tabelle entfernt werden, damit ein Objekt getestet werden kann, ohne sich Gedanken über die Verletzung eines Primärschlüssels machen zu müssen.
 
Identitätsspaltenabhängigkeit
 

 Genau wie eine Primärschlüsseleinschränkung ist auch die Identitätsspalte eine Abhängigkeit. Daher ist es nicht erforderlich, die Logik für die automatische Inkrementierung der Identitätsspalte für die Prozedur AddEmployee zu testen; es muss um jeden Preis vermieden werden.
 
Isolieren von Abhängigkeiten beim Komponententest
 

 Wir können alle drei Abhängigkeiten verhindern, indem wir die Einschränkungen vorübergehend aus der Tabelle entfernen und uns dann für den Komponententest nicht auf die Daten in der Datenbank verlassen. So werden die Standard-Datenbanktests geschrieben.
 

 In diesem Fall könnte man sich fragen, woher die Daten für die Employee-Tabelle stammen. Die Antwort ist, dass die Tabelle mit Testdaten gefüllt wird, die im Komponententest definiert wurden.
 
Ändern der gespeicherten Prozedur für Einheitentests
 

 Lassen Sie uns nun die Abhängigkeiten in unserem Komponententest entfernen:
 

 [expand title="Code"]
 
 – Simulation eines abhängigkeitsfreien Komponententests zum Testen der gespeicherten Prozedur „AddEmployee“ ALTER PROCEDURE TestAddEmployeeASBEGIN – (1) Assemble – Neue Mitarbeiterdaten einrichten DECLARE @NAME VARCHAR(40) ='Adil' ,@StartDate DATETIME2 ='2018- 03-01' ,@Title VARCHAR(50) ='Entwicklungsmanager' -- Aktuelle Tabelle setzen DROP TABLE Employee -- Tabelle löschen, um Abhängigkeiten zu entfernen CREATE TABLE Employee -- Tabelle ohne Abhängigkeiten erstellen (PRIMARY KEY und IDENTITY(1,1 )) (EmployeeId INT DEFAULT(0) ,NAME VARCHAR(40) ,StartDate DATETIME2 ,Title VARCHAR(50) ) – Einrichten der erwarteten Tabelle ohne Abhängigkeiten (PRIMARY KEY und IDENTITY(1,1) CREATE TABLE #EmployeeExpected ( EmployeeId INT DEFAULT(0) ,NAME VARCHAR(40) ,StartDate DATETIME2 ,Title VARCHAR(50) ) -- Fügen Sie die erwarteten Tabellendaten hinzu INSERT INTO #EmployeeExpected (NAME, StartDate, Title) VALUES (@NAME, @StartDate, @Title) -- (2) Act -- Rufen Sie AddEmployee auf, um neue Mitarbeiterdaten zur Employee-Tabelle EXEC A hinzuzufügen ddEmployee @NAME ,@StartDate ,@Title -- (3) Assert -- Gleicht die aktuelle Tabelle mit der erwarteten Tabelle ab DECLARE @ActualAndExpectedTableCommonRecords INT =0 -- wir gehen davon aus, dass die erwarteten und tatsächlichen Tabellendatensätze nichts gemeinsam haben SET @ActualAndExpectedTableCommonRecords =(SELECT COUNT(*) FROM (SELECT e.EmployeeId ,e.NAME ,e.StartDate ,e.Title FROM Employee e INTERSECT SELECT ee.EmployeeId ,ee.NAME ,ee.StartDate ,ee.Title FROM #EmployeeExpected ee) AS A) DECLARE @ExpectedTableExcluldingActualTable INT =1 – wir gehen davon aus, dass die erwartete Tabelle Datensätze enthält, die in der tatsächlichen Tabelle nicht vorhanden sind SET @ExpectedTableExcluldingActualTable =(SELECT COUNT(*) FROM (SELECT ee.EmployeeId ,ee.NAME ,ee.StartDate ,ee .Title FROM #EmployeeExpected ee EXCEPT SELECT e.EmployeeId ,e.NAME ,e.StartDate ,e.Title FROM Mitarbeiter e) AS A) IF @ActualAndExpectedTableCommonRecords =1 AND @ExpectedTableExcluldingActualTable =0 PRINT '*** Test bestanden! ***' ELSE PRINT '*** Test fehlgeschlagen! ***' -- Zeigen Sie die tatsächlichen und erwarteten Tabellen vor dem Vergleich an #EmployeeExpected ee – Tabelle zurücksetzen (Einschränkungen nach dem Komponententest zurücksetzen) DROP TABLE Employee DROP TABLE #EmployeeExpected CREATE TABLE Employee (EmployeeId INT PRIMARY KEY IDENTITY (1, 1) ,NAME VARCHAR(40) ,StartDate DATETIME2 ,Title VARCHAR (50) );ENDE
 

 [/expandieren]
 
Abhängigkeitsfreien simulierten Einheitentest ausführen
 

 Führen Sie den simulierten Komponententest aus, um die Ergebnisse anzuzeigen:
 
-- Ausführen des abhängigkeitsfreien simulierten Komponententests zur Überprüfung der gespeicherten Prozedur AddEmployeeEXEC TestAddEmployee
 

 
 

 Führen Sie den Komponententest erneut aus, um die gespeicherte Prozedur AddEmployee zu überprüfen:
 
-- Ausführen des abhängigkeitsfreien simulierten Komponententests zur Überprüfung der gespeicherten Prozedur AddEmployeeEXEC TestAddEmployee
 

 
 

 Herzliche Glückwünsche! Abhängigkeiten aus dem Unit-Test wurden erfolgreich entfernt.
 

 Selbst wenn wir jetzt einen neuen Datensatz oder eine Reihe neuer Datensätze zur Tabelle „Employee“ hinzufügen, wirkt sich dies nicht auf unseren Komponententest aus, da wir die Daten- und Einschränkungsabhängigkeiten erfolgreich aus dem Test entfernt haben.
 
Erstellen eines Datenbankkomponententests mit tSQLt
 

 Der nächste Schritt besteht darin, einen echten Datenbank-Einheitentest basierend auf dem simulierten Einheitentest zu erstellen.
 

 Wenn Sie SSMS (SQL Server Management Studio) verwenden, müssen Sie das tSQLt-Framework installieren, eine Testklasse erstellen und CLR aktivieren, bevor Sie den Komponententest schreiben und ausführen.
 

 Wenn Sie dbForge Studio für SQL Server verwenden, können Sie den Einheitentest erstellen, indem Sie mit der rechten Maustaste auf die gespeicherte Prozedur AddEmployee klicken und dann auf „Einheitentest“ => „Neuen Test hinzufügen…“ klicken, wie unten gezeigt:
 

 
 

 Um einen neuen Test hinzuzufügen, geben Sie die erforderlichen Unit-Test-Informationen ein:
 

 
 

 Verwenden Sie zum Schreiben des Komponententests das folgende Skript:
 
-- Kommentare hier sind mit dem Test verbunden.-- Beispiele für Testfälle finden Sie unter:http://tsqlt.org/user-guide/tsqlt-tutorial/CREATE PROCEDURE [BasicTests].[test if new employee can hinzugefügt werden]ASBEGIN --Assemble DECLARE @NAME VARCHAR(40) ='Adil' ,@StartDate DATETIME2 ='2018-03-01' ,@Title VARCHAR(50) ='Development Manager' EXEC tSQLt.FakeTable "dbo.Employee " -- Dadurch wird eine abhängigkeitsfreie Kopie der Employee-Tabelle erstellt. CREATE TABLE BasicTests.Expected -- Erwartete Tabelle erstellen ( EmployeeId INT ,NAME VARCHAR(40) ,StartDate DATETIME2 ,Title VARCHAR(50) ) -- Erwartete hinzufügen Tabellendaten INSERT INTO BasicTests.Expected (NAME, StartDate, Title) VALUES (@NAME, @StartDate, @Title) --Act EXEC AddEmployee @Name -- Fügt Daten in die Employee-Tabelle ein, @StartDate, @Title --Assert EXEC tSQLt.AssertEqualsTable @Expected =N'BasicTests.Expected' ,@Actual =N'dbo.Employee' ,@Message =N'Aktuelle Tabelle stimmt mit erwarteter Tabelle überein' ,@FailMsg =N'Aktuelle Tabelle stimmt nicht mit erwarteter Tabelle überein'END;GO
 

 Führen Sie dann den Datenbankkomponententest aus:
 

 
 

 Herzliche Glückwünsche! Wir haben erfolgreich einen Datenbank-Einheitentest erstellt und ausgeführt, der frei von Abhängigkeiten ist.
 
Dinge zu tun
 

 Das ist es. Nachdem Sie diesen Artikel durchgearbeitet haben, können Sie Abhängigkeiten von Datenbankkomponententests isolieren und Datenbankkomponententests frei von Daten- und Einschränkungsabhängigkeiten erstellen. Infolgedessen können Sie Ihre Fähigkeiten verbessern, indem Sie die folgenden Dinge tun:
 
     
  1. Bitte versuchen Sie, die gespeicherte Prozedur Delete Employee hinzuzufügen, und erstellen Sie einen simulierten Datenbankkomponententest für Delete Employee mit Abhängigkeiten, um zu sehen, ob es unter bestimmten Bedingungen fehlschlägt
    2. 
 
  2. Bitte versuchen Sie, die gespeicherte Prozedur Delete Employee hinzuzufügen, und erstellen Sie einen Datenbankkomponententest ohne Abhängigkeiten, um zu sehen, ob ein Mitarbeiter gelöscht werden kann
    3. 
 
  3. Bitte versuchen Sie, die gespeicherte Prozedur Search Employee hinzuzufügen, und erstellen Sie einen simulierten Datenbankkomponententest mit Abhängigkeiten, um zu sehen, ob nach einem Mitarbeiter gesucht werden kann
    4. 
 
  4. Bitte versuchen Sie, die gespeicherte Prozedur Search Employee hinzuzufügen, und erstellen Sie einen Datenbankkomponententest ohne Abhängigkeiten, um zu sehen, ob nach einem Mitarbeiter gesucht werden kann
    5. 
 
  5. Bitte versuchen Sie komplexere Anforderungen, indem Sie gespeicherte Prozeduren erstellen, um die Anforderungen zu erfüllen, und dann Datenbankkomponententests ohne Abhängigkeiten schreiben, um zu sehen, ob sie den Test bestehen oder nicht bestehen. Stellen Sie jedoch sicher, dass der Test wiederholbar ist und sich auf das Testen der Einheit des Codes konzentriert
    6. 
 
 
 
Nützliches Tool:
 

 dbForge Unit Test – eine intuitive und komfortable GUI zur Implementierung automatisierter Unit-Tests in SQL Server Management Studio.