Hello, > > 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. [...] Insbesondere, wenn man von Status-, bzw. Fehlerbehandlung nichts hält, weil ja keine Fehler auftreten können, weil sie nicht auftreten dürfen. Das ist ähnlich, wie mit Atommüllfabriken. Da treten auch nie Fehler auf ;-P Eine Web-Datenbank wird i.d.R. im dynamischen Multiuserumfeld betrieben. Drauf feuern alse ggf. hunderte von Userprozessen gleichzeitig Requests ab. Man weiß also nur selten ganz genau, welche Knoten dabei entstehen können. Testen alleine reicht also nicht. Man muss auch eine möglichst vollständige Fehlerbehandlung einbauen. __ "Fehler" steht hier nicht für falsche Programmierung, sondern dafür, dass ein durchzuführender Request nicht wie gewünscht beantwortet werden konnte. __ Glück Auf Tom vom Berg -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz

Hello, > > 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. [...] Insbesondere, wenn man von Status-, bzw. Fehlerbehandlung nichts hält, weil ja keine Fehler auftreten können, weil sie nicht auftreten dürfen. Das ist ähnlich, wie mit Atommüllfabriken. Da treten auch nie Fehler auf ;-P Eine Web-Datenbank wird i.d.R. im dynamischen Multiuserumfeld betrieben. Drauf feuern alse ggf. hunderte von Userprozessen gleichzeitig Requests ab. Man weiß also nur selten ganz genau, welche Knoten dabei entstehen können. Testen alleine reicht also nicht. Man muss auch eine möglichst vollständige Fehlerbehandlung einbauen. ** "Fehler" steht hier nicht für falsche Programmierung, sondern dafür, dass ein durchzuführender Request nicht wie gewünscht beantwortet werden konnte. ** Glück Auf Tom vom Berg -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz

Hello, > > 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. [...] Insbesondere, wenn man von Status-, bzw. Fehlerbehandlung nichts hält, weil ja keine Fehler auftreten können, weil sie nicht auftreten dürfen. Das ist ähnlich, wie mit Atommüllfabriken. Da treten auch nie Fehler auf ;-P Eine Web-Datenbank wird i.d.R. im dynamischen Multiuserumfeld betrieben. Drauf feuern alse ggf. hunderte von Userprozessen gleichzeitig Requests ab. Man weiß also nur selten ganz genau, welche Knoten dabei entstehen können. Testen alleine reicht also nicht. Man muss auch eine möglichst vollständige Fehlerbehandlung einbauen. **"Fehler" steht hier nicht für falsche Programmierung, sondern dafür, dass ein durchzuführender Request nicht wie gewünscht beantwortet werden konnte. ** Glück Auf Tom vom Berg -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz