Unittests in beruflichen SW-Projekten.
-
Umfrage: Wieviele Unittests habt ihr für Software die ihr beruflich entwickelt?
Auswahl Stimmen Prozent Keine 17 51.5% Wenige und die meisten sind veraltet und gehen nicht mehr. 2 6.1% Wenige die alle funktionieren 3 9.1% Für ungefähr die Hälfte der testbaren SW gibt es Tests, aber viele sind veraltet und gehen nicht mehr. 1 3.0% Für ungefähr die Hälfte der testbaren SW gibt es Tests die alle funktionieren 5 15.2% So gut wie alles was geht wird mit Unittests getestet, aber einige sind veraltet und gehen nicht mehr. 0 0.0% So gut wie alles was geht wird mit Unittests getestet. 5 15.2% Wieviele Unittests habt ihr für Software die ihr beruflich entwickelt?
-
Wir haben sogar eine Konvention eingeführt, dass der Unit-Test C des Unit-Test B für den Unit-Test A von mindestens zwei Agents durchgeführt werden muss, weil Unit-Test A dann automatisch überall auf der Welt wiederverwendet werden soll ... Um die Permutation durchzuziehen brauchst Du dann acht Leute und das für statistisches Testen
http://de.wikipedia.org/wiki/Statistischer_Test
Der Koller für Quick&Dirty Coder :D.Ich wäre Dir dankbar, wenn Du in Springfield genauso verfahren würdest. Wer braucht schon ein zweites Tschernobyl.
-
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Neuigkeiten aus der realen Welt in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Wir haben eine Test-Abdeckung des gesamten Server-Codes von ~95% (Business Layer, Persistence Layer). Den Client-Code testen wir allerdings nur manuell.
-
Bei uns laufen ca. 2 Stunden Testfälle, die die Bedienung der Oberfläche simulieren und dabei möglichst alles abdecken. (Die Simulation ist dabei, dass tatsächlich die ganzen Fenster aufpoppen, Felder mit Werten gefüllt werden, Buttonklicks simuliert werden usw.) "mal eben" einen Dreizeiler fixen heißt also tatsächlich, dass nach fünf Minuten Arbeit die Tests auf einem Server gestartet werden und zwei Stunden später die Änderung eingecheckt wird, wenn die Tests erfolgreich waren.
-
pumuckl! Das sind doch dann aber keine Unittests?! Ihr testet zwar Funktion A über Button A, aber letztendlich doch nur das Zusammenspiel der GUI. Unter einem Unittest versteht man eher den Algorithmus, ohne das drum herum. GUI ist doch schon "zu viel" für einen Unittest.
Wir haben beides: Unittests die einzelne Klassen bzw. ihre Methoden einzelnen testen. Dafür benutzen wir xUnit. Alle Unittests werden einmal gestartet und im Batch abgearbeitet. Diese Tests laufen immer in der IDE durch, weil keine GUI getestet werden muß. Wenn man echtes TDD macht, müssten die xUnit-Testst im 24h im Loop in der IDE des Entwicklers laufen.
Die grafischen Tests machen wir am Ende, weil die GUI ja nur die View ist. Da will man ja nur wissen, ruft Button A auch Funktion A auf? Wenn das passiert, wird die Richtigkeit von Funktion A durch den Unittest garantiert. Ich stelle mir das auch ziemlich schwer vor, in der GUI die Ergebnisse zu testen. Es ist doch viel einfacher Programmcode zu testen. Weiterhin besteht bei Tests über die GUI das Problem, sobald sich die GUI ändert, mußt du auch den Test anpassen. Bei einem Unittest kannst du die View täglich ändern, der Algorithmus wird aber immer gleich getestet.
-
Artchi schrieb:
Wenn man echtes TDD macht, müssten die xUnit-Testst im 24h im Loop in der IDE des Entwicklers laufen.
Oder noch besser: Continous Integration!
http://en.wikipedia.org/wiki/Continuous_integration#Make_the_build_self-testing
-
Artchi schrieb:
Die grafischen Tests machen wir am Ende, weil die GUI ja nur die View ist. Da will man ja nur wissen, ruft Button A auch Funktion A auf? Wenn das passiert, wird die Richtigkeit von Funktion A durch den Unittest garantiert. Ich stelle mir das auch ziemlich schwer vor, in der GUI die Ergebnisse zu testen. Es ist doch viel einfacher Programmcode zu testen. Weiterhin besteht bei Tests über die GUI das Problem, sobald sich die GUI ändert, mußt du auch den Test anpassen. Bei einem Unittest kannst du die View täglich ändern, der Algorithmus wird aber immer gleich getestet.
Full Ack. Allerdings ist es bei alten Systemen extrem schwer, Unittests zu etablieren, weil es häufig gar nicht kleine "Units" gibt, die man testen könnte.
Wenn man eine Anwendung schreibt und von vorne herein so viel wie möglich unit-testet, dann schreibt man den Code automatisch so, dass man ihn auch testen kann. Macht man das aber nicht, dann ist der Code häufig so unstrukturiert. Dann sind die Funktionen schnell mit dem GUI-Code vermischt. Oder es gibt zig Seiteneffekte.
Dann ist so ein System wie oben schrieben (automatischer GUI Test) keine schlechte Sache.
-
Artchi schrieb:
pumuckl! Das sind doch dann aber keine Unittests?! Ihr testet zwar Funktion A über Button A, aber letztendlich doch nur das Zusammenspiel der GUI. Unter einem Unittest versteht man eher den Algorithmus, ohne das drum herum. GUI ist doch schon "zu viel" für einen Unittest.
Jein - tatsächliche Unit-Tests haben wir nur teilweise. Allerdings decken die Gesamttests gute 99% des Codeumfangs ab. Und es geht eben nicht nur um das zusammenspiel der GUI sondern auch um die Werte, die nach den Eigaben vom Rechenkern geliefert werden. Die Mathematik hinter der Sache ist ziemlich komplex. Für den Rechenkern Unittests zu schreiben wäre z.B. viel zu aufwändig, zumal ein Großteil der möglichen Eingaben eh durch die darüberligende Fachlogik verhindert wird.
Und wie byto schon sagt ist es ein gewachsenes System, wo Teile schon einige Jahre auf dem Buckel haben und nicht alles besteht aus Einheiten, die klein genug sind um vernünftige Unit-Tests für einzelne Klassen zu schreiben.
-
pumuckl schrieb:
Jein - tatsächliche Unit-Tests haben wir nur teilweise. Allerdings decken die Gesamttests gute 99% des Codeumfangs ab.
Gemessen oder geschätzt?
-
Jester schrieb:
Gemessen oder geschätzt?
Gemessen - allerdings vor nem halben Jahr. Wies bei den neueren Features aussieht weiß ich nicht, allerdings werden dafür immer Fleißig Pflichtenheft-Tests erstellt die dann zu den allgemeinen Tests nach den Builds hinzugefügt werden.
-
pumuckl schrieb:
Jester schrieb:
Gemessen oder geschätzt?
Gemessen...
Respekt
-
Am schwersten war bisher das Testen von OpenGL/Direct3D-Renderingausgaben, weil man nicht einfach ein Referenzbild als PNG speichern und einen simplen Vergleich machen kann, denn je nach Hardware gibt es immer kleine Differenzen. Der Test muss also fuzzy sein, und die Schwellwerte, ab dem man sagt "es ist falsch", sind nicht einfach zu finden. Ich bin dabei, es mir so einzurichten, dass die Tests nie falsche Positive, aber durchaus falsche Negative ausgibt. Wenn ein Test anscheinend fehlgeschlagen ist, muss ich es bestätigen oder ablehnen.
Man könnte auf die Basis natürlich ein Bayes-Netz oder ein neuronales Netz bauen, damit man einen lernfähigen Klassifikator hat .... aber das ist dann schon ein Overkill