nicht angemeldet
Hallo,
Prinzipiell solltest Du (idealerweise ;) ), alles testen, was eine einzelne, gekappselte Einheit (daher "Unit-Test") in Deiner Software beschreibt.
Es ist in der Regel problematisch, einen Unit-Test zu schreiben, der mehr als eine Komponente beinhaltet. Erstens ist es dann eigentlich kein "Unit-Test" mehr, zweitens kann man den kompletten Test wegwerfen, sobald man nur eine einzelne Komponente austauscht, drittens lässt sich dann ein eventueller Fehler um so schwerer finden, weil Du mehrere Komponenten untersuchen musst.
In Deinem konkreten Fall:
Ich stelle mir da jetzt mal so vor, Du hast in Deiner Anwendung 4 Komponenten (vielleicht siehts bei Dir auch etwas anders aus)
1.) Datenbank-System
2.) Persistenzschicht (ein OR-Mapper, oder ein paar Klassen, die die Inhalte der Datenbank auslesen/verändern und daraus Objekte bauen) (siehe Modell im MVC-Modell)
3.) Business-Logik (Controller im MVC)
4.) Template-Engine (View im MVC)
Streng genommen müsstest Du nun diese 4 Komponenten jede für sich Unit-testen. Bei der Datenbank kannst Du aber vermutlich gutgläubig davon ausgehen, dass sie funktioniert :), also bleiben noch die anderen drei
Also bräuchtest Du mindestens 3 Unit-Tests.
Der Witz dabei ist nun, dass Du die jeweils anderen Komponenten durch Dummy-Objekte (Mocks) ersetzt, die verlässlich immer genau das liefern was Du brauchst. Somit stellst Du sicher, dass ein Test für eine Komponente nur dann fehlschlägt, wenn es wirklich an dieser Komponente liegt.
Wenn Du also z.b. die Template-Engine testen willst, baust Du einen "ControllerMock", der genau das liefert, was Du gerade testen willst, und überprüfst dann, ob die Template-Engine auch richtig darauf reagiert.
Wenn Du den Controller testen willst, baust Du einen "PersistenceMock" welcher anstelle der echten Datenbank-Schicht Objekte ausspuckt, und stellst dann im Test sicher, dass der Controller diese Daten so aufbereitet, wie es die Template-Engine erwartet.
Auf der anderen Seite, solange keine größere Logik dabei ist die etwas >berechnet, würde es doch reichen hier auf der Webseite selbst die Dinge zu >testen. Also wirklich Browser auf und gucken ob alles richtig angezeigt >wird.
Dies mag funktionieren, wenn Deine Anwendung klein und überschaubar ist - in so einem Fall rentiert sich auch manchmal der Aufwand für Unit-Tests nicht.
Wenn Du aber z.b. an einer großen Webanwendung schraubst, an der täglich dutzende Entwickler herumpfuschen, möchtest Du das nicht mehr manuell tun, sondern einen automatisierten Prozess, der Alarm schlägt, sobald irgend etwas nicht mehr funktioniert (siehe Continous Integration). Das geht nur über Unit-Tests oder vergleichbare Methoden.