Ich bin Software-Ingenieur/Architekt und selbstständig. Tests haben mir und dem Team schon so oft den Allerwertesten gerettet! Meine Empfehlung => schreibt unbedingt "hinreichende" Tests! Dass Tests Zeit kosten und deshalb ausgelassen werden ist kein Argument.
[gr] Dass keine Tests zu schreiben, Geld spart, ist leider ein tatsächlich sehr weit verbreiteter Irrglaube - in dem Zusammenhang vielleicht auch lesenswert: www.heise.de/developer/artikel/Guenstigere-Software-durch-weniger-Tests-4656247.html Insofern kann ich mich Deiner Empfehlung nur anschließen 😊
“Der Code ist so gut, den braucht man nicht testen.” Der Spruch ist gut und manchmal kann man den auch bringen. Aber selbst bei gutem Code wird man testen, nur anders. Es werden keine trivialen Dinge oder Null-Referenzen o. Ä. getestet, sondern eher komplexe Interaktionen von Modulen, deren Richtigkeit sich durch Architektur und bloßes Hinsehen alleine nicht erschließt. Davon abgesehen möchte man natürlich Regressionssicherheit haben.
[gr] Ich kam mir damals etwas auf den Arm genommen vor - wenn Dich jemand explizit dafür holt, um Schwachstellen zu identifizieren, weil die Qualität nicht stimmt, und Du nach 2 Minuten sagst, es gibt ja auch keine Tests, und dann der Satz kommt, dann denkt man sich seinen Teil …
Meiner Erfahrung nach entsteht guter Code erst mit einer guten Testabdeckung. Ich merke oft erst im Unit-Test, dass meine Methode bspw. nicht gut geschnitten ist, weil ich viel zu viel Mocken muss um das Verhalten zu testen. Gute Tests zu schreiben ist allerdings eine Kunst. Wenn Testing sich wie Ballast anfühlt, macht man definitiv etwas falsch. Ich persönlich benutze Unit-Test oft aktiv für die Entwicklung, indem ich den Test zuerst schreibe und anschließend die vorher getestete Unit implementiere und den Test damit grün mache. Klappt wunderbar.
Ich kenne es als Given/When/Then - Pattern. Es ist sehr hilfreich. Ideal gibt es in dem eingestzten Testframework bereits eine entsprechende DSL.
Ich bin Software-Ingenieur/Architekt und selbstständig.
Tests haben mir und dem Team schon so oft den Allerwertesten gerettet!
Meine Empfehlung => schreibt unbedingt "hinreichende" Tests!
Dass Tests Zeit kosten und deshalb ausgelassen werden ist kein Argument.
[gr] Dass keine Tests zu schreiben, Geld spart, ist leider ein tatsächlich sehr weit verbreiteter Irrglaube - in dem Zusammenhang vielleicht auch lesenswert: www.heise.de/developer/artikel/Guenstigere-Software-durch-weniger-Tests-4656247.html
Insofern kann ich mich Deiner Empfehlung nur anschließen 😊
Kannte ich noch nicht. Werde ich auf jedenfall verwenden.
[gr] Freut mich 😊
“Der Code ist so gut, den braucht man nicht testen.”
Der Spruch ist gut und manchmal kann man den auch bringen.
Aber selbst bei gutem Code wird man testen, nur anders. Es werden keine
trivialen Dinge oder Null-Referenzen o. Ä. getestet, sondern eher komplexe
Interaktionen von Modulen, deren Richtigkeit sich durch Architektur und bloßes
Hinsehen alleine nicht erschließt.
Davon abgesehen möchte man natürlich Regressionssicherheit haben.
[gr] Ich kam mir damals etwas auf den Arm genommen vor - wenn Dich jemand explizit dafür holt, um Schwachstellen zu identifizieren, weil die Qualität nicht stimmt, und Du nach 2 Minuten sagst, es gibt ja auch keine Tests, und dann der Satz kommt, dann denkt man sich seinen Teil …
Meiner Erfahrung nach entsteht guter Code erst mit einer guten Testabdeckung. Ich merke oft erst im Unit-Test, dass meine Methode bspw. nicht gut geschnitten ist, weil ich viel zu viel Mocken muss um das Verhalten zu testen. Gute Tests zu schreiben ist allerdings eine Kunst. Wenn Testing sich wie Ballast anfühlt, macht man definitiv etwas falsch. Ich persönlich benutze Unit-Test oft aktiv für die Entwicklung, indem ich den Test zuerst schreibe und anschließend die vorher getestete Unit implementiere und den Test damit grün mache. Klappt wunderbar.