Hallo,

ich habe gerade folgendes Problem:

Mehrere PDF-Formulare sollen gefüllt werden, dabei gibt es bei den Formularen einen allgemeinen Bereich der bei allen identisch ist, und einen Spezialbereich. Für die Werteerfassung gibt es einen Dialog, die Daten werden in einer Instanz einer Klassen "gespeichert" für die Weiterverarbeitung.

Nun gibt es für die Formulare ein Regelwerk wie die ausgefüllt werden müssen, z.B. muss immer ein Name angegeben werden bzw. aus 3 Möglichkeiten mind. eine max. alle ausgewählt werden.

Dieser Validator eignet sich meiner Meinung hervorragend für den Einstieg ins Unittesting - nur bin ich mir über die Umsetzung unschlüssig.

Teste ich mit dem Unittesting jetzt gezielt die einzelnen Prüfungen (z.B. "Name muss <> ''" sein, oder "WertA OR WertB OR WertC") oder teste ich an der Stelle die dahinterliegende Businesslogik? Damit meine ich: Gibt es am Ende für jedes Zielformular einen eigenen Unittest, in dem ich alle für das Formular geforderten Tests durchführe?

Aus dem Bauch raus würde ich gerne gegen die BUsinesslogik prüfen, denn dann weiß ich genau, welches Formular am Ende korrekt raus kommt. Da sich die Regeln ändern können, kann ich nach einer Anpassung genau sagen, ob die Änderung bei einem anderen Formular einen Fehler hervorruft (d.h. die Validierung nicht mehr stimmt).

Auf der anderen Seite erzeuge ich so jede Menge redundanten Testcode bzw. führe einen Test (bzw. div. Testfälle) auf eine Funktion mehrfach aus....

Wenn der Validator auf einer Datenklasse arbeitet würde ich den Validator mit verschiedenen Konstellationen von Daten auf die Korrektheit seiner Ausgabe prüfen.

Wenn du alles getrennt hast, dann wird dein Formular ja bloß die Datenklasse dahinter über seine Controls befüllen und dann auf Knopfdruck oder so die Validierung antriggern.

Für einen Validator bzw die einzelnen Prüfungen eignet sich übrigens gut das Specification Pattern.

Zitat von Stevie:

Wenn der Validator auf einer Datenklasse arbeitet würde ich den Validator mit verschiedenen Konstellationen von Daten auf die Korrektheit seiner Ausgabe prüfen.

d.h. konkret die reine Funktionalität des Validators prüfen, nicht kontrollieren, ob die eigentliche Geschäftslogik korrekt abgebildet ist

Zitat von Stevie:

Wenn du alles getrennt hast, dann wird dein Formular ja bloß die Datenklasse dahinter über seine Controls befüllen und dann auf Knopfdruck oder so die Validierung antriggern.

so soll es werden

Zitat von Stevie:

Für einen Validator bzw die einzelnen Prüfungen eignet sich übrigens gut das Specification Pattern.

Danke, schau ich mir an...

Zitat von Lemmy:

Zitat von Stevie:

Wenn der Validator auf einer Datenklasse arbeitet würde ich den Validator mit verschiedenen Konstellationen von Daten auf die Korrektheit seiner Ausgabe prüfen.

d.h. konkret die reine Funktionalität des Validators prüfen, nicht kontrollieren, ob die eigentliche Geschäftslogik korrekt abgebildet ist

Nun, das kommt darauf an, welchen Umfang der Validator hat. Prüft er nur ob z.B. Pflichtfelder ausgefüllt sind oder es sich um eine gültige email Addresse handelt oder auch eine Plausibilitätsprüfung der gesamten Eingabe. Letzteres dürfte schon in Richtung Geschäftslogik gehen. Da kommt es aber drauf an, wie die Implementiert ist. Denn es gibt durchaus Systeme, wo das nicht hardcodiert sondern einstellbar ist. Wobei letztes sich schon eher Richtung Integrationstest (mehrere Programmteile in Interaktion miteinander) anstatt Unittest (eine Einheit in Isolation) gehen würde.

Zitat von Stevie:

Denn es gibt durchaus Systeme, wo das nicht hardcodiert sondern einstellbar ist. Wobei letztes sich schon eher Richtung Integrationstest

Nicht, wenn man in diesem Fall einfach gegen die Spezifikation der konfigurierbaren Prüfung testet. Denn es ist ja unerheblich, welche Einstellung vorgenommen wird.