Gibt es einen Wert beim Komponententest für automatisch implementierte Eigenschaften?

Ich betrachte im Allgemeinen jeden Code, der keine Aktion ausführt, als nicht testbar. Dies bedeutet in der Regel, dass ich Eigenschaften (automatisch oder nicht implementiert) nicht teste, da sie nur einen Wert festlegen oder zurückgeben.

Dies wird sich ändern, wenn der Getter oder Setter einer Eigenschaft irgendeine Art von "Arbeit" ausführt, wie möglicherweise einen von zwei (oder mehr) Werten basierend auf dem Zustand eines anderen Feldes / Eigenschaft / was auch immer zurückzugeben.

Wenn Sie es nicht gesehen haben, empfehle ich Roy Osherove Buch über Unit Testing . Es behandelt alle Arten von "Was zu testen und wann" Fragen, einschließlich dieser.

Das hängt davon ab, ob Sie testen, ob eine API einer erwarteten Gruppe von Eigenschaften entspricht oder ob Sie, wie Sie demonstrieren, nur den Zugriff testen und die Eigenschaften festlegen.

In dem Beispiel, das du gibst, würde ich nein sagen.

Aktualisieren

Übereinstimmung mit der erwarteten API; Wenn Sie indirekt auf Eigenschaften zugreifen, z. B. in einer Reflektions- / dynamischen Umgebung, und Sie verwenden Zugriffsaufrufe für Eigenschaften und Methoden, um zu überprüfen, ob eine unbekannte API einer erwarteten entspricht.

Das Testen der Einstellungen und das Abrufen von Eigenschaften sollten im Kontext des Testens einer Geschäftsfunktion des Objekts erfolgen. Wenn die Eigenschaft nicht durch eine Geschäftsfunktion getestet wird, war entweder die Eigenschaft nicht erforderlich oder Sie benötigen weitere Tests. Ich würde vorschlagen, dass Sie die Eigenschaften hinzufügen, während Sie die Tests hinzufügen, die sie benötigen, anstatt sie vor dem Schreiben von Tests hinzuzufügen.

Indem Sie die Geschäftsfunktion testen, behandeln Sie den Code aus der Perspektive des Komponententests eher als Black Box. Auf diese Weise können Sie die Implementierungsdetails mit einem geringeren Einfluss auf die Tests ändern. Da Refactor eine wichtige (und oft übersehene) Stufe des TDD-Zyklus ist, bedeutet dies viel weniger Code-Bearbeitung. Sie können auch erkennen, dass (zum Beispiel) die Eigenschaft keinen öffentlichen Setter haben sollte und sollte durch eine Methode zugewiesen werden, die Validierung und andere Geschäftslogik durchführt.

Unit-Tests sollten sich auf Testfunktionen beschränken, die Sie in Ihrer Anwendung implementieren.

Sie sollten API / SDK nicht testen, auf die Ihre Anwendung angewiesen ist. Teilweise, weil es Zeitverschwendung ist (will Ihr Unternehmen für Sie das SDK / API von X-Third-Party testen?), Und teilweise weil es "Rauschen" in Ihre Komponententestsuite einführt. Der Kontext Ihrer Komponententestbibliothek sollte sein, nur den Code in Ihrer Anwendung zu testen.