Da diese Annotationen sehr deklarativ sind, hat es wenig Sinn, Komponententests zu schreiben, die einfach (mit Reflektion) überprüfen, dass die Methoden kommentiert sind - die Tests würden nur den Produktionscode duplizieren. Und das würde immer noch die Möglichkeit lassen, dass die Annotationen nicht so verwendet werden, wie das Framework sie erwartet (vielleicht sind sie die falschen Annotationen, sie sind am falschen Ort, oder ihnen fehlt eine zusätzliche Konfiguration).
Ein aussagekräftiger Test wäre also kein Komponententest, sondern ein Integrationstest, der sicherstellt, dass das System die Annotationen korrekt erkennt. Um die Geschwindigkeit vernünftig zu halten, versuchen Sie, diese Integrationstests so fokussiert wie möglich zu gestalten, indem Sie so wenig wie möglich vom Framework instanziieren (was eine gründliche Kenntnis des Frameworks voraussetzt - RTFS). Nicht zuletzt könnte ein End-to-End-Test die korrekte Verwendung der Annotationen überprüfen, indem der HTML-Code analysiert und überprüft wird, ob die Validierungsfehler angezeigt werden, wenn ungültige Daten in die Felder eingegeben werden.
Es sollte nur ein paar Integrations/Ende-zu-Ende-Tests geschrieben werden, um sicherzustellen, dass die Validierung aktiviert wurde. Es sollte nicht notwendig sein, jedes Feld zu testen, wenn alle gleich funktionieren.
Was machen diese Datenanmerkungen? Ist es Validierung oder etwas anderes? –
Es markiert eine Komponente, die validiert werden soll. Ein praktisches Beispiel für die manuelle Validierung mit Datenannotationen: http://odetocode.com/blogs/scott/archive/2011/06/29/manual-validation-with-data-annotations.aspx –