Bei einem Projekt, das zu 95% aus Datenbankinteraktionen besteht: inwieweit machen da Unit Tests Sinn (außer vielleicht bei den Verbleibenden 5%)? Vor allem bei Daten, die von Usern eingegeben werden, oder aus fremden Systemen importiert werden stelle ich mir solche Tests schwierig vor. Reicht da nicht, zu prüfen, ob die Unit auf die zu erwartenden Daten funktioniert?
Und wie ist es mit ActionListener aus z.B. Managed Beans, die ja Usereingaben verarbeiten?
also zum einen kannst du die Datenbankanbindung wegmocken, dafür gibts verschiedene Frameworks oder nen Kollege machts einfach mit Groovy
Aber gerade die Stellen wo user Daten eingibt oder aus fremden Systemen was kommt machen Unittests Sinn, weil was passiert wenn der User Mist eingibt oder die Verbindung zum Fremdsystem sich komisch verhält?
Das kommt ganz darauf an. Für Unit-Tests bietet sich wie erwähnt Mocken an. Oder, falls die Architektur es zulässt, du erzeugst dir ein ganzes Test-Setup. Als z.B. eine HSQLDB statt deines Dev-DB-Servers in dem du vor jedem Testlauf die notwendigen Daten reinschießt. Das ist auch ganz praktisch für Demonstrationen.
Aber sind das nicht die Sachen, an die ein Entwickler nicht gedacht / erwartet hat … somit kann er auch ja kein Test dafür entwickeln. Oder kommt hier zum tragen, dass er sich bei dem Test darum intensiver Gedanken macht?
Musst hier ghanz klar zwischen Unit Test und Integrationstest unterscheiden.
Unit Test testen (am besten alle) Zeilen deines Codes direkt (Whitebox), Integrationstest testen ein Modul/System ohne zu wissen was „drinnen“ ist (Blackbox).
Ausfaelle der DB Verbindung zB. kann man in Integrationstests nachstellen, aber wie soll sich denn dein System dann verhalten?
Soll dein System mit sowas umgehen koennen, ausser eine Meldung die auf „Game Over“ hinauslaeuft?
Falls dein zu testender Code eine DB Verbindung benötigt oder sogar Ergebnisdaten von DB Abfragen, dann musst du diese DB Interaktion mocken. Falls dein Code nicht so einfach gemockt werden kann, solltest du erstmal diese Baustelle angehen, z.B. mehr in Methoden oder Klassen auslagern und diese dann mocken.
Es reicht nie aus nur auf die erwarteten Daten zu testen. So entstehen Sicherheitslücken.
[QUOTE=freezly;67891]
Und wie ist es mit ActionListener aus z.B. Managed Beans, die ja Usereingaben verarbeiten?[/QUOTE]
Hier solltest du deinen Code so schreiben, dass das was du als Unit Test unabhängig testen kannst, auch sauber gekapselt wurde. Dann interessiert dich nicht, ob diese Unit in einer ManagedBean oder sonstwo verwendet wird, du willst lediglich sicherstellen, dass diese Unit den Input korrekt verarbeitet, egal woher der Input kommt.
[QUOTE=freezly;67891]
Oder kommt hier zum tragen, dass er sich bei dem Test darum intensiver Gedanken macht? [/QUOTE]
Ganz genau.
[QUOTE=maki;67929]
Unit Test testen (am besten alle) Zeilen deines Codes direkt (Whitebox), …[/QUOTE]
Naja, ich kenne nemanden der 100% Code Coverage empfiehlt, aber über diese Diskussion kann man endlos streiten.
ja genau deshalb sollte man dafür unittests schreiben um alles abzufangen, genau das sind die Dinge die z.B. SQL Injection ermöglichen oder andere Dinge.
Du musst alle Eingaben des Users validieren und das geht am besten per Unittest
