nicht angemeldet
Moin,
Entwickler die das benutzen möchten sollten das auch dürfen, aber man sollte keine Entwickler dazu zwingen.
Da stimme ich mit dir ueberein. Wozu man Entwickler meiner Meinung nach jedoch (berechtigter Weise) zwingen darf (und das tue ich auch), sind Tests im Allgemeinen.
Der Artikel sagt aber auch, dass es extrem schwer sein soll die Testgetriebene Entwicklung zu lernen und sie anzuwenden.
Es braucht schon seine Zeit, da liegst du mit deiner Aussage richtig. In vielen unterschiedlichen Projekten habe ich jedoch haeufig festgestellt, dass Entwickler, die bis dato nicht mit TDD entwickelt haben, nach ein paar Monaten sich eine nicht-test-getriebene Entwicklung nur noch schwer vorstellen koennen.
Irgendwann gelangt man an den Punkt, an dem man der Meinung ist, nur Code, der entsprechend getestet ist, sei valider Code - und Code, der nicht getestet ist, ist nicht relevant und darf entfernt werden. Natuerlich ist das uebertrieben, aber solange die Qualitaet dadurch steigt, ist es eine willkommene Einstellung.
Es ist von groszen Vorteil, wenn man TDD in einem Team mit erfahrenen Entwicklern lernen kann. Denn haeufig reicht die Theorie nicht aus, und mit ein zwei real-world examples erklaeren sich die Dinge dann recht schnell.
Außerdem war der Autor der Meinung, dass er jetzt stärker auf testbaren Code achtet (was glaube ich zu deiner Anmerkung über testbaren Code passt).
Ja, genau, das war das, was ich mit den design principles zu erklaeren versucht habe.
Nimmst du sowas wie Sona Qube um die Testabdeckung zu prüfen?
Sonaqube hat durchaus seine Vorteile, gerade was Code Smells angeht. Ich kann zu der Benutzung raten. Wenn es dir jedoch ausschlieszlich um Code-Coverage geht, dann wuerde ich mir mal JaCoCo o.ae. naeher anschauen. IntelliJ (zum. in Verbindung mit Gradle) bietet Code-Coverage z.B. bereits von Hause aus an (run with coverage).
Es sei noch gesagt, dass Testabdeckung nicht nur schwarz-weisz betrachtet werden sollte. Am Anfang ist das Ziel einer 100%igen Abdeckung ehrenhaft - da man dabei dann auch sehr viel lernt. In echten Projekten koennen aber auch 85% oder 90% zufriedenstellend sein - vorausgesetzt, dass es e2e-Tests gibt, die zumindest einmal jeden moeglichen Workflow durchlaufen, so dass es dennoch "knallt", sollten Contracts gebrochen werden.
Aber bedenke, bei Reduzierung von Testabdeckung schwindet prozentual die Vergewissheit, dass der Code das tut, was er tun soll.
U.a. mit Docker soll ich mich jetzt ab dem 01.06 als frisch beginender Applikationsentwickler auseinander setzen. Ich bin gespannt.
Na, das ist doch toll! Bist du Teil eines Teams?
Cheers, markk