Hallo, da hier wohl viele IT-Leute herumschwirren mal eine klassische IT-Frage. Schreibt ihr Unittests? Oder schreibt ihr gleich korrekten Code? In meinem Projekt wollen se jetzt was gegen die Haiders und ungetesten Code machen, und jetzt soll ich Unittests für meinen Code schreiben. Dabei fällt mir auf welcher Pain-In-The-Ass das sein kann, wenn man das nachträglich macht. Wir haben auch kein schönes Unittest-Framework wie z.B. GoogleTest sondern irgendwas anderes (glaub das ist selbstgebaut), welches den Rückgabecode der Anwendung überprüft, und wenn natürlich != 0 dann Test failed.
Schreibt ihr Tests für eure Software [IT-Thema]
- Umfrage: Schreibt ihr Tests für eure Software
- Ja, freiwillig (6 — 14,3%)
- Ja, weil ich eine gewisse % Testabdeckung brauche um committen zu können (2 — 4,8%)
- Selten, aber es kommt schon mal vor (7 — 16,7%)
- Nein (7 — 16,7%)
- Was sind Tests? (17 — 40,5%)
- Ich programmiere in FORTRAN 77 und echte Männer schreiben gleich korrekten Code. TDD my ass. (3 — 7,1%)
-
Mod/RDW
#1 Sylvester 26 Mai 2022, 22:58 -
-
Mod/RDW
-
#4 Bernd Lauert 27 Mai 2022, 00:22Auf der Arbeit generell nicht, weil die Kunden das nie bezahlen wollen. Müssen dann halt nach der Abhnahme dementsprechend für die Updates bluten.
-
#5 Rollatormann 27 Mai 2022, 00:35Nein, lul. Paar motivierte Mitarbeiter haben den ein oder anderen Test geschrieben, habens dann aber aufgegeben weil wir einfach keine Tests durchführen.
Aber ist in unserer Industrie auch etwas schwer, ist keine normale Business Sohluschen. -
Mod/RDW
#6 BigBANG 27 Mai 2022, 22:44Für meine privaten Projekte schreibe ich nur Tests, wenn ich komplizierten Code geschrieben habe. Da ich ein guter Programmierer bin, schreibe ich jedoch keinen komplizierten Code. Schachmatt.
Nachträglich würde ich ebenfalls keine Tests schreiben wollen. Wenn das nicht von Anfang an eingeplant wurde, ist es ein absoluter pain in the ass.
ABER:
Wenn ich heute ein neues Projekt anlege, würde ich mich an die Best Practices halten. Vorallem, weil ich mit dem Microsoft Technology Stack und C# arbeite. Ich behaupte ganz dreist, dass in diesem Umfeld der beste und robusteste Code "erforscht" wird. Hier werden die neusten Design Patterns entdeckt und eingesetzt.
Keine Community holt sich so sehr einen auf Architektur-Design und Code Patterns runter, wie die C# .NET nerds. Und ich liebe es und finde es richtig so.
C++-Devs interessieren sich nicht dafür, weil die Community anders tickt. Web-Devs (Javascript) interessieren sich noch weniger für solche Dinge.
Unit Tests sind extrem wichtig für große, professionelle Projekte, an denen mehrere Entwickler arbeiten. Software-Architekturen werden nach ihrer Testfreundlichkeit bewertet.
Also ja, ich würde immer Unit-Tests schreiben. Sie sind ein Qualitätsmerkmal deiner Software.
Beispiel:
Die Clean Code Architektur ist so aufgebaut, dass deine Entities und Business Logik nichts über deine Datenbank und äußeren Schnittstellen wissen. Sie kommunizieren auschließlich mit Interfaces, die sich innerhalb ihrer eigenen Schicht befinden.
Das hat 2 Vorteile:
- Du kannst sämtliche äußeren Resourcen wegmocken und die gesamte Business-Logik testen, ohne das Gesamtsystem starten zu müssen.
- Deine Software läuft unabhängig von dem Framework, das gerade en vogue ist. Deine Business-Logik übersteht jeden Technologie-Trend und muss nicht angefasst werden.
Sobald mehrere Entwickler an einem Projekt arbeiten, wird es passieren, dass jemand einen Teil anfassen muss, den jemand anderes geschrieben hat.
Wenn derjenige etwas kaputt macht, wird es über Unit-Tests erkannt. (Bei einem gescheiten DevOps-Setup wird der Merge nicht akzeptiert, weil deine Build-Pipeline die Tests automatisiert ausführt und Merges ablehnt, wenn Tests failen).
Zudem sind Tests ein sinnvolles Tool, um fremden Code besser zu verstehen.
Wenn du ein größeres Projekt hast, das keine Unit Tests besitzt und die ursprünglichen Entwickler nicht mehr da sind, ist es automatisch Legacy Code. Ohne Tests kann Software langfristig nicht überleben. -
-
Mod/RDW
-
Mod/RDW
#9 BigBANG 27 Mai 2022, 22:52
Zitat von: ProfHase
Statische Code Analysen und Coding Guidelines finde ich ja relativ praktisch, aber den Sinn von Modultests habe ich bis heute nicht verstanden. Das ist insofern nur sinnvoll, wenn das jemand anders macht, so dass eine neutrale Instanz intensiv drüber schautOder wenn du Code änderst und wissen willst, ob jetzt irgendein anderer Teil deiner Software kaputt gegangen ist. -
Mod/RDW
#10 Sylvester 27 Mai 2022, 23:29
Zitat von: BigBANG
Hier werden die neusten Design Patterns entdeckt und eingesetzt.Viel mehr Design Patterns als die von Gang of Four sind mir nicht bekannt. C# haben wir hier auch nicht. Nur Java, Python und C++ (da bin ich). Es fällt mir auch auf dass viele Leute die C++ programmieren auch nicht mehr auf dem neuesten Stand sind. Ich bin wohl der Einzige der Smart Pointer (
Keine Community holt sich so sehr einen auf Architektur-Design und Code Patterns runter, wie die C# .NET nerds.std::unique_ptrundstd::shared_ptr) nutzt.
Zu C# kann ich generell nicht viel sagen. Ich habe es mal auf Linux installiert, ein bisschen rumgespielt und dann gesehen, dass es auch auf Linux Dateien mit ".exe" Endung erzeugt. Finde das ziemlich befremdlich. Dann lieber Python. -
-
#12 Gelöschtes Mitglied 78 31 Mai 2022, 21:09
Gut, dass die Frage nach den Tests mal gestellt wird! Hatte mich schon gefragt, was die Experten dazu sagen. lel
Bei meinem letzten """Großprojekt""" wollte ich es unbedingt richtig machen und habe einige Unit-Tests geschrieben. Ich bin allerdings nur eingeschränkt davon überzeugt.
Ein nicht unwesentlicher Teil des Programms bestand darin, Sachen semi-menschenlesbar auszugeben. Wenn ich da zwei Platzhalter vertauscht habe und zwei Sachen an der Stelle der jeweils anderen auftauchen, ist das natürlich ein richtiges Problem. Wie soll man solche Dinge automatisiert testen? Wahrscheinlich gar nicht.
An anderen Stellen habe ich Unit Tests geschrieben, aber das war eher oberflächlich und kam mir teilweise sinnlos vor. Man fittet eben nicht nur den Code an den Test heran, sondern auch den Test an den Code.
Ich habe auch gefixte Bugs in Tests verwandelt, aber auch da ist mir nur sehr eingeschränkt klar, ob das sinnvoll ist. Wird jemals einer hergehen und Scheiße bauen und dadurch den gleichen Bug wieder einbauen, den ich schon repariert habe?
Ich habe im Übrigen auch nicht mit Mocks gearbeitet, habe keine Ahnung was das ist.
Vollends lächerlich wird es, wenn "Test-driven Development" propagiert wird und dass man keinen Kot schreiben darf ohne vorher einen Test geschrieben zu haben.
Davon dass ihr hier sagt, bei euch ist mit Tests auch nicht so viel los, sehe ich mich bestätigt, ebenso wie von diesem Artikel: https://www.teamten.com/lawrence/programming/mostly-avoid-unit-tests.html
Zitat von: BigBANGDie Clean Code Architektur ist so aufgebaut, dass deine Entities und Business Logik nichts über deine Datenbank und äußeren Schnittstellen wissen. Sie kommunizieren auschließlich mit Interfaces, die sich innerhalb ihrer eigenen Schicht befinden.Fick dich! Fick dich! Fick dich!
Das hat 2 Vorteile:
Als ich einmal fröhlich am vor mich hin programmieren war, kam plötzlich ein Kollege (kein Informatiker) an meinen Schreibtisch, mit dem Buch "Clean Code" von Robert C. Martin unterm Arm. Da habe ich ziemlich die Nase gerümpft.
Habe dennoch die ersten ca. 30 Seiten des Buches gelesen und was soll ich sagen, es war kompletter Schwachsinn und ich habe alle meine Vorurteile über dieses Thema bestätigt gesehen. Und dann hab ich dem Kollegen gesagt dass er ein Affenn***r ist und mich in Ruhe lassen soll.
€: Der Behauptung dass man den Eingabe/Ausgabe-Teil vom Logik-Teil trennen sollte, stimme ich allerdings zu. Aber bitte nicht übertreiben mit dem Engineering. Jede zusätzliche Funktion ist eine zusätzliche mentale Last für jeden der den Code lesen wird. Von Klassen ganz zu schweigen. Dieser Beitrag wurde von Gelöschtes Mitglied 78 am 31.05.2022 21:16:31 bearbeitet. -
-
Mod/RDW
#14 Sylvester 31 Mai 2022, 23:03
Zitat von: ahaha_a_gnu
Ich habe im Übrigen auch nicht mit Mocks gearbeitet, habe keine Ahnung was das ist.Ein Mock ist im Prinzip etwas, was man vorspielt (to mock=vorspielen). Netzwerkcode zum Beispiel. Requests zum Server.
Zitat von: ahaha_a_gnumit dem Buch "Clean Code" von Robert C. Martin unterm Arm. Da habe ich ziemlich die Nase gerümpft.Das Clean Code Buch ist voll von "Allgemeinplätzen". Jemand der seit ein paar Jahren Software entwickelt sollte auf diese "Weisheiten" von selbst gekommen sein.
Unit Tests sind trotzdem wichtig. Leider verhält es sich mit Unit Tests genauso wie mit dem programmieren. "Übung macht den Meister" und "Es ist noch kein Meister vom Himmel gefallen". -
Mod/RDW
#15 Sylvester 5 Juni 2022, 21:54
kleiner Nachtrag:
Zitat von: ahaha_a_gnumit dem Buch "Clean Code" von Robert C. Martin unterm Arm.
Statt dem Buch "Clean Code" würde ich eher zu diesem Buch greifen:
Adaptive Code: Agile coding with design patterns and SOLID principles
Das behandelt die SOLID-Prinzipien, und die sind die Basis um gut testbaren Code zu schreiben. -
#16 Deleted member 206 5 Juni 2022, 22:02
Ich persönlich schreibe keine Tests für meine Software (unabhängig davon, ob das Projekt groß oder klein ist), muss allerdings dazu sagen, dass ich gar keine Software schreibe
-
-
#18 Gelöschtes Mitglied 78 5 Juni 2022, 22:14
Zitat von: Hexley
kleiner Nachtrag:Hat "Agile" im Subtitel und ein Microsoft-Logo vorne drauf, muss also gut sein. Clean Code erfüllt nur eines dieser beiden Qualitätsmerkmale.
Statt dem Buch "Clean Code" würde ich eher zu diesem Buch greifen:
Adaptive Code: Agile coding with design patterns and SOLID principles
Das behandelt die SOLID-Prinzipien, und die sind die Basis um gut testbaren Code zu schreiben. -
Mod/RDW
#19 Sylvester 5 Juni 2022, 22:17
Zitat von: ahaha_a_gnu
Hat "Agile" im Subtitel und ein Microsoft-Logo vorne drauf, muss also gut sein. Clean Code erfüllt nur eines dieser beiden Qualitätsmerkmale.Bücher von Microsoft sind tatsächlich besser als deren Software, und Bücher können deine Daten nicht an Microsoft schicken im Gegensatz zu der Software. -
#20 Beate 16 Juni 2022, 15:30Ich habe schon mehrfach erlebt, dass man trotz ausführlichster Unit-Tests immer noch mit großen Fehlern durchkommt, vor allem wenn man die Tests dann selbst auch schreibt. Da laufen die Tests dann mal gerne zufällig richtig durch, weil man den Code dann an irgendwelche oberflächlichen Assertions in den Tests anpasst. Entweder man deckt jeden kleinsten x-beliebigen Case ab, braucht dann aber drölf Stunden, um allein die Tests zu konzipieren oder man macht sich lieber im Voraus besser Gedanken, bevor man losprogrammiert.
Dieser Beitrag wurde von Beate am 16.06.2022 15:37:05 bearbeitet.
