Hallo,

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

wenn man anfängt, Business-Code in Form von Triggern als SQL zu schreiben, dann ändert sich der SQL-Code wahrscheinlich ähnlich häufig wie anderer Code. Und dann sollte man auch den SQL-Code Unit-Testen.

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.

Ich teste ja nicht eine Query, sondern ich teste ein Funktion, in der das Query drinnen steht. Und das kann (und sollte man m.E.) auch entsprechend testen, so dass nur die Dinge passieren, die man auch will. Insbesonders wenn ein UPDATE dank Triggern noch viele Nebeneffekte haben kann.

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.

Wenn Statements tatsächlich generiert werden stimme ich dir zu. Wenn Statements aber als SQL (oder einer Vorform davon wie JPQL) im Code eingebettet sind ist es Code und sollte auch getestet werden.

Nenn es meinetwegen Integrationstest statt Unit-Test und separiere es - ändert aber nichts daran dass man es automatisiert testen kann und sollte.

VG Matti