Schreibt ihr Unittests?
-
Shade Of Mine schrieb:
Tim schrieb:
Es muss ja nicht unbedingt der Code komisch sein, es ist ja oft so, dass die Spezifikationen (eines Programmteils) nicht eindeutig/komplett sind. Da kann man dann so gesehen nicht auf Korrektheit prüfen, hat aber doch den Vorteil, dass man beim Test solche Schwachstellen in der Spezifikation auzeigt.
Ich weiss aber nicht ob besserwisser das gemeint hat.Mir faellt gerade keine Situation ein wo ich keine sinnvollen Pre/PostConditions definieren kann.
Ich kann dir gerne ein paar abtreten
Shade Of Mine schrieb:
Wenn natuerlich die Spezifikation selbst zu schwammig ist, dann haben wir aber dank der Unittest bereits einen Fehler gefunden: naemlich dass die Definition zu schwammig ist - sobald man das ausgebessert hat, kann man aber auch einen Unittest schreiben...
Genau so meinte ich es auch in meinem Beitrag
-
Valhalla schrieb:
Wenn ja, für wieviel Prozent eures Codes und für welche Sprache?
in prozent kann ich's nicht sagen. vielleicht 60...70%. einiges kann auf dem pc getestet werden, einiges muss direkt auf der hardware laufen. simulatoren taugen meistens mix. sprache: C
-
Shade Of Mine schrieb:
Wenn natuerlich die Spezifikation selbst zu schwammig ist, dann haben wir aber dank der Unittest bereits einen Fehler gefunden: naemlich dass die Definition zu schwammig ist - sobald man das ausgebessert hat, kann man aber auch einen Unittest schreiben...
Dazu brauche ich keinen Unittest um dies zu sagen... In manchen Firmen ist dies der Standard (TM), und Informationen bekommt man auch beim Nachharken nur tröpfchenweise (Was zudem entweder den Vorwurf einbringt das man das ja wissen müsste [bei maximal 3 Sätzen Beschreibung für ein neues Softwaremodul!] oder das man nicht genügend selbstständig denkt [sofern man die Spezifikation weder kennt, noch Kontakt zum Kunden hat wird das schwer - Ich kann zwar aus meiner sich Rahmenbedingungen annehmen ob diese stimmen ist aber zweifelhaft] oder das allgemeine "keine Zeit"-Syntom).
Nein, ich schreibe in meiner derzeitigen Firma (wobei ich dort auch nicht mehr lange bin) tatsächlich keine Unittests, den ohne Spezifikationen keine sinnvollen Unittests. Zumal Unittests ja auch noch Zeitaufwand bedeuten, und wehe man investiert Zeit...
cu André
-
asc schrieb:
Dazu brauche ich keinen Unittest um dies zu sagen... In manchen Firmen ist dies der Standard (TM), und Informationen bekommt man auch beim Nachharken nur tröpfchenweise (Was zudem entweder den Vorwurf einbringt das man das ja wissen müsste [bei maximal 3 Sätzen Beschreibung für ein neues Softwaremodul!] oder das man nicht genügend selbstständig denkt [sofern man die Spezifikation weder kennt, noch Kontakt zum Kunden hat wird das schwer - Ich kann zwar aus meiner sich Rahmenbedingungen annehmen ob diese stimmen ist aber zweifelhaft] oder das allgemeine "keine Zeit"-Syntom).
Jede Funktion die ich schreibe hat definierte Vor und Nachbedingungen. Da kann mir der Rest des Codes relativ egal sein.
Die Anforderungen an Module sind oftmals sehr schwammig, keine frage - aber ich habe noch nie definiert bekommen, dass ich diese funktion und jene funktion so und so umsetzen soll - ergo kann ich definierte vor und nachbedingungen haben.
wenn man diese definitionen nicht festhaelt, ist der code nicht testbar. unittest laufen ja nicht auf komplette module, sondern auf einzelne funktionen.
-
@Tim: dein Posting klang halt so als ob du in so "schwammig" definierten Fällen einfach garkeine Unit-Tests schreibst, und es nichtmal versuchst
-
Benutzt ihr Frameworks für die Unittests, oder einfach nur ne "exe" mit main?
-
asc schrieb:
Nein, ich schreibe in meiner derzeitigen Firma (wobei ich dort auch nicht mehr lange bin) tatsächlich keine Unittests, den ohne Spezifikationen keine sinnvollen Unittests. Zumal Unittests ja auch noch Zeitaufwand bedeuten, und wehe man investiert Zeit...
Hm, meiner Meinung nach ersetzen Unittests detaillierte Spezifikationen, denn letztere bekommst du sowieso in der Regel nicht. Der Test nagelt dann das Verhalten fest.
-
ich hab mit fehlenden bedingungen gemeint, dass man zb keine gui sinnvoll unittesten kann. an der uni haben wir eine note schlechter bekommen, weil wir die gui und die datenbankanbindung nicht unitgetestet haben.
-
Shade Of Mine schrieb:
Die Anforderungen an Module sind oftmals sehr schwammig, keine frage - aber ich habe noch nie definiert bekommen, dass ich diese funktion und jene funktion so und so umsetzen soll - ergo kann ich definierte vor und nachbedingungen haben.
Da hast du natürlich recht, ändert aber nichts daran das es Zeit kostet, was wiederum ein Grund für die Firma dagegen ist (Wir müssen sparen, koste es was es wolle).
cu André
-
Nun die Zeit reinvestiert sich wieder. Sicher ich kenn das Argument, allerdings kosten Fehler die früher erkannt werden um 10-1000 fach weniger.
-
Zeus schrieb:
Sicher ich kenn das Argument, allerdings kosten Fehler die früher erkannt werden um 10-1000 fach weniger.
Das ist mir bekannt, die Entscheidungen treffen aber andere...
Mir wäre es auch lieber wenn in allen Firmen sauber entwickelt und sinnvoll entschieden wird, nur man kann sich dies nicht immer aussuchen (bzw. man kann es schon, sonst würde ich ja nicht die Firma wechseln).
cu André
-
Kann man grafische Ausgaben (GUI, 3d-Renderzeugs etc) mit vertretbarem Aufwand anders testen, als es einfach auszuprobieren?
-
hustbaer schrieb:
@Tim: dein Posting klang halt so als ob du in so "schwammig" definierten Fällen einfach garkeine Unit-Tests schreibst, und es nichtmal versuchst
Nunja, wenn die Spec schwammig ist kann ich grundsätzlich zwei Dinge machen:
a) ich definiere das Ergebnis, siehe Bashar
b) ich fordere eine genauere Spec einDie Entscheidung ist im Einzelnen zu treffen, auch Mischformen sind möglich (z.B. mache ich einen Vorschlag der dann abgenickt wird, etc.).
Es gibt zwar auch noch...
c) nichts
... aber das ist schlecht wenn ich mit meinen Eiern bürge
-
asc schrieb:
Da hast du natürlich recht, ändert aber nichts daran das es Zeit kostet, was wiederum ein Grund für die Firma dagegen ist (Wir müssen sparen, koste es was es wolle).
Kenn ich nur zu gut. Natuerlich ist es global gesehen Dumm wegen Zeit auf Unittests zu verzichten da Unittests zeit sparen - aber das ist leider gang und gebe in der industrie. denn die leute die sowas entscheiden sehen meistens nicht weit genug.
als programmierer kann man da nichts machen, keine frage.
-
Shade Of Mine schrieb:
asc schrieb:
Da hast du natürlich recht, ändert aber nichts daran das es Zeit kostet, was wiederum ein Grund für die Firma dagegen ist (Wir müssen sparen, koste es was es wolle).
Kenn ich nur zu gut. Natuerlich ist es global gesehen Dumm wegen Zeit auf Unittests zu verzichten da Unittests zeit sparen
An solchen indizien kann man schon bei dem bewerbungsgespraech die qualitaet der firma erkennen, und wie sicher der eigene job sein wird.
nightly build
backups
version system
bug/task datenbank
unittestsich wuerde nicht sagen dass nur wegen unittests eine firma gut oder schlecht ist, aber von meiner erfahrung her kann mal ein nachmittag arbeit spaeter akkumuliert tage sparen.
fuer alles unittests zu schreiben waere natuerlich zuviel des guten, aber wenn etwas viel benutzt wird und ueber lange zeit verlaesslich laufen soll, kann ich es mir garnicht ohne vorstellen.
