Frage zu Triggern in SQL

[Rolf B]

Hallo Matti,

SQL Queries ändern sich normalerweise seltener als Programmcode, deswegen ist die Testhäufigkeit geringer; denke ich.

Einen Test, der beweist, dass ein UPDATE nur den gewünschten Satz verändert - wozu? Du musst doch nicht den SQL Server testen. Du schreibst deine SQL Statements, testest sie in der SQL Workbench oder phpmyadmin, und wenn sie tun, was sie sollen, musst du keine Unit-Tests mehr dafür haben.

Im Zusammenhang mit einem UPDATE musst Du nur testen, ob dein Code das korrekte Update-Statement erzeugt. Dafür musst Du die Statementgenerierung von der Statementausführung so trennen, dass Du die Generierung testen kannst, ohne das Statement auszuführen. Beispielsweise mit einem gemockten PDO (in PHP). Prepared statements vereinfachen das, da sind die Statements fix und es muss nichts generiert werden. Natürlich hat man auch da schonmal Szenarien wo SQL zusammengebaut wird. Aber auch dann gilt: Du musst testen, ob der SQL Generator das erwartete SQL liefert, und Du musst die Typen von SQL Statements, die dann entstehen können, gegen die DB geprüft haben. Ersteres ist Teil eines Unit-Tests, letzeres nicht.

Natürlich ist es sinnvoll, eine SQL Testsuite zu haben, die von einem Datenbankzustand A ausgeht, einen Haufen SQL ausführt und dann prüft, ob der erwartete Zustand B erreicht ist. Durch Assertions nach jedem einzelnen Statement kann man die fehlerhafte Stelle schnell finden und auch sicher sein, dass sich zwei Fehler nicht gegenseitig aufheben. Aber diese Testsuite gehört nicht in den ständigen Unit-Test, den man im Build hat oder in einem gated checkin. Dafür ist sie, wie Du richtig schreibst, zu aufwändig.

Und ob dein Businesscode korrekt mit der DB-Schnittstelle interagiert, das ist ein Test auf einer anderen Ebene. Für den brauchst Du die DB nicht, dafür mockst Du die DB. Andernfalls testest Du zu viel auf einmal.

Zumindest wurde mir das Unit-Testkonzept so vermittelt.

Rolf