Testet ihr eure Software automatisch?
-
es kann sehr wohl sinnvoll sein, Testfälle aus dem Code herzuleiten, beispielsweise um für beide Zweige einer (jeder) if-Anweisung Testfälle zu haben, oder gezielt Grenzfälle testen, um off-by-1-errors zu detektieren, Fehlerzustände zu provozieren, um zu testen, ob diese korrekt behandelt werden usw
-
großbuchstaben schrieb:
...Testfälle aus dem Code herzuleiten, beispielsweise um für beide Zweige einer (jeder) if-Anweisung Testfälle zu haben,...
Du programmierst wohl gegen die Implementierung und nicht die Schnittstelle, nehme ich mal an...
-
Manche Leute brauchen 100% Abdeckung, da muß man dann auch auf die Ergebnisse reagieren.
-
Tyrdal schrieb:
Manche Leute brauchen 100% Abdeckung, da muß man dann auch auf die Ergebnisse reagieren.
1. Es ist das eine nachträglich Tests zu ergänzen und anzupassen, als diese erst nachträglich zu schreiben (mit der großen Gefahr nur den Code wie er ist zu testen ohne Anforderungen etc. zu berücksichtigen).
2. Ein Test soll das SOLL dokumentieren und absichern und nicht das IST.
3. TDD soll auch zu schlankeren Code führen, weil man eben genau das umsetzt, was auch durch Anforderungen und Tests gefordert ist.
-
Unittests gehen noch klar. Die sorgen auch dafür, dass die Unit wiederverwendbar ist, schließlich muss die Unit irgendwie im Test kompilieren (ohne den ganzen anderen Rest). Hatte mal ein Projekt wo Geräte verschiedenster Hersteller Daten laut Standard schicken sollen. Also zack, solche Daten besorgt und Unittests für den Parser geschrieben.
Das ist schon ein angenehmes Gefühl, wenn man eine Änderung in der Bibliothek macht, comitted und auf dem Server sofort für jedes Geräte geprüft wird, ob die Software noch so läuft wie vorher
-
Wie Integrationstest in der Praxis funktionieren sollen ist mir schleierhaft, vlt. mag jemand was dazu erläutern?