Verwenden Sie Unit-Tests bei der Arbeit? Welchen Nutzen ziehen Sie daraus? [geschlossen]

Ich hatte geplant, Unit-Tests zu studieren und auf meinen Code anzuwenden, aber nach einem Gespräch mit meinen Kollegen haben mir einige vorgeschlagen, dass dies nicht notwendig ist und nur einen geringen Nutzen hat. Sie behaupten auch, dass nur wenige Unternehmen Unit-Tests mit Produktionssoftware durchführen.

Ich bin neugierig, wie die Leute Unit-Tests bei der Arbeit angewendet haben und welche Vorteile sie daraus ziehen, z. B. bessere Codequalität, kürzere Entwicklungszeiten auf lange Sicht usw.

Einige von ihnen schlagen mir vor, dass es nicht notwendig ist

Nun, im eigentlichen Sinne haben sie Recht: Tests, Code-Reviews, Quellcodeverwaltung usw. sind ebenfalls nicht unbedingt erforderlich . Nur die wenigsten vernünftigen Entwickler arbeiten langfristig ohne diese. Die meisten von uns haben (oft auf die harte Tour, aus eigenen Fehlern) gelernt, warum dies Best Practices sind.

und es hat einen sehr geringen Nutzen.

Dies ist nicht in den meisten Fällen richtig. Das heißt, wenn wir über Produktionssoftware sprechen, die in den kommenden Jahren im Einsatz - also in der Wartung - sein soll.

Sie behaupten auch, dass nur wenige Unternehmen Unit-Tests mit Produktionssoftware durchführen.

Dies mag zutreffen (wenn auch meiner Erfahrung nach immer weniger), aber es hat nichts über den Wert von Unit-Tests zu sagen . Im Gegensatz dazu der alte Witz "Scheiße ist gut - 50 Milliarden Fliegen können nicht falsch sein!" ;-)

Haben Sie bei Ihrer Arbeit einen Unit-Test durchgeführt und was haben Sie davon? (zB bessere Codequalität, Zeitersparnis etc.)

Ich wende in meiner Arbeit seit über 10 Jahren Unit-Tests an, wann immer dies möglich war. Dieses Gefühl des Vertrauens in meinen Code, zu wissen, dass er funktioniert - und ich kann es jederzeit und überall in wenigen Sekunden immer wieder beweisen , anstatt nur daran zu glauben - ist von unschätzbarem Wert. Es gibt mir den Mut, meinen Code umzugestalten, sein Design zu verbessern oder Fehler zu beheben, ohne befürchten zu müssen, vorhandene Funktionen zu beschädigen. Ich würde nie wieder in diese alten Zeiten des "Code and Pray" zurückkehren.

Ich mache Unittests, aber nicht (oder nur wenige) bei der Arbeit

Die Hauptvorteile von Tests, die ich bekomme, sind, dass das Refactoring viel einfacher ist und dass eine Regression (dh die Wiedereingliederung von Fehlern, die bereits behoben wurden) bemerkt wird.

Testen lebt mit dem Build: Sie checken Software aus, während Tests ausgeführt werden, und Sie checken erst ein, wenn alle Tests mit Ihrer Änderung ausgeführt werden.

Meiner Erfahrung nach ist das Schreiben von Tests praktisch nutzlos, wenn es als Einzelgänger durchgeführt wird. Wenn Sie Ihre Tests immer korrigieren müssen, um den vorgenommenen Änderungen Rechnung zu tragen, wenn die Tests möglicherweise von Ihren Mitarbeitern gelöscht werden (was bei meinen vorherigen Jobs der Fall war), weil sie mich nicht bereitstellen lassen usw., sind sie nur zusätzliche Aufgaben Die Vorteile, die der Rest des Teams sofort in Kauf nimmt.

Wenn das gesamte Team zustimmt (und in einem Team von 1, das einfach ist), sind Tests meiner Erfahrung nach ein großer Vorteil für die Qualität, den Stil und die Robustheit des Projekts.

Aber in einem Team, das ehrlich glaubt, dass "nur wenige Unternehmen ihren Code automatisch testen" und davon überzeugt sind, dass sie sowieso Zeitverschwendung sind, scheint es wenig Hoffnung zu geben, die Vorteile zu verdienen, aber eine große Chance, dass Sie gemacht werden verantwortlich für den "Zeitverlust", wenn auf Fehler hingewiesen wird.

Die beste Möglichkeit, Tests einzuführen, ist ein kleines Projekt, das in Ihrer alleinigen Verantwortung liegt. Dort hätten Sie die Möglichkeit zu glänzen und den Wert von Tests zu demonstrieren.

Ich stehe eher auf der Seite Ihrer Kollegen, aber nur bis zu einem gewissen Punkt.

Das Problem bei Unit-Tests ist, dass sie häufig und sinnlos in trivialen Fällen geschrieben sind, in denen eine flüchtige Untersuchung des Codes ergibt, dass es auf jeden Fall funktionieren wird. Zum Beispiel:

def add(x, y)
  x + y
end

Zusammen mit einem Dutzend Tests, um sicherzustellen, dass die Addition tatsächlich für willkürlich ausgewählte Anwendungsfälle funktioniert. Duh ...

Die allgemeine Prämisse hinter Unit-Tests lautet: Wenn Ihr Code keine Fehler enthält, liegt das daran, dass Sie nicht genug getestet haben. Nun, wann schreibt man die richtigen Komponententests? Antworten:

1. Wenn Sie testen
2. Beim Debuggen
3. Während du wirklich knifflige Dinge entwickelst

Lassen Sie uns jeden einzelnen Schritt durchgehen und davon ausgehen, dass Sie eine Art Web-App entwickeln.

Sie schreiben Code für neue Funktionen und dieser sollte inzwischen einigermaßen gut funktionieren. Sie greifen dann zu Ihrem Browser und überprüfen, ob er funktioniert, indem Sie ihn intensiver testen, oder? Bzzzt! ... Falsche Antwort. Sie schreiben einen Komponententest. Wenn Sie dies jetzt nicht tun, werden Sie es wahrscheinlich nie tun. Und dies ist einer der Orte, an denen Unit-Tests sehr gut funktionieren: um Funktionalität auf hohem Niveau zu testen.

Sie entdecken dann einen Bug (der nie einen übersieht?). Dies bringt uns zu Punkt zwei. Sie tauchen wieder in den Code ein und folgen den Schritten. Schreiben Sie dabei die Komponententests an wichtigen Unterbrechungspunkten, an denen es auf konsistente und korrekte Daten ankommt.

Letzter Punkt ist umgekehrt. Sie entwerfen einige haarige Funktionen, die eine Menge Metaprogrammierung beinhalten. Es führt schnell zu einem Entscheidungsbaum mit Tausenden von möglichen Szenarien, und Sie müssen sicherstellen, dass jedes einzelne von ihnen funktioniert. Wenn man solche Dinge schreibt, kann eine einfach aussehende Veränderung hier oder dort unvorstellbare Konsequenzen in der Nahrungskette haben. Angenommen, Sie entwerfen eine MPTT-Implementierung mit SQL-Triggern, sodass sie mit Anweisungen mit mehreren Zeilen funktionieren kann.

In dieser heiklen Umgebung sollten Sie Ihre Tests in der Regel stark automatisieren. Sie schreiben also Skripte, um die Generierung von Testdaten zu automatisieren, und führen eine Bootsladung von Komponententests mit diesen Testdaten durch. Eine wichtige Sache, die Sie dabei nicht aus den Augen verlieren sollten, ist, dass Sie auch Komponententests für Ihren Komponententestgenerator schreiben müssen.

Fazit: Unit-Tests, definitiv ja. Ersparen Sie sich jedoch die Grundfunktionen, bis Sie sie tatsächlich für das Debuggen benötigen oder sicherstellen, dass einige Funktionen ordnungsgemäß funktionieren (einschließlich der Tests selbst in letzterem Fall).

Der gesamte Code muss getestet werden. Da gibt es keine Wahl.

Ungetesteter Code ist nutzlos: Man kann ihm nicht trauen, etwas zu tun.

Sie können Komponententests schreiben oder Sie können hoffen, Integrations- oder Abnahmetests auf höherer Ebene zu schreiben.

Unit-Tests sind einfacher zu schreiben, einfacher zu debuggen und einfacher zu verwalten.

Integrationstests basieren auf der Annahme, dass die Einheiten tatsächlich funktionieren. Woher wissen Sie, dass die Einheiten ohne Unit-Tests funktionieren? Wie können Sie einen Integrationstest debuggen, wenn Sie nicht wissen, dass die einzelnen zu integrierenden Einheiten tatsächlich funktionieren?

In ähnlicher Weise hängen Abnahmetests von allen Teilen und Teilen ab, die funktionieren. Woher wissen Sie, dass Teile und Komponenten funktionieren, ohne eine Reihe von Komponententests durchzuführen?

Tests sind obligatorisch. Alle übergeordneten Tests hängen von den tatsächlich funktionierenden Einheiten ab.

Das macht Unit-Tests zu einer logischen Notwendigkeit. Es gibt keine andere Wahl.

Ich verwende Unit-Tests für alles, was ich schreibe, und lasse keinen ungetesteten Code ohne einen Testfall durchgehen. (Aber mir fehlt ein Berichterstattungstool, deshalb muss ich über Testberichterstattung nachdenken. Eine Sache zu einer Zeit ...)

Ganz einfach: Wenn Sie nicht nachweisen können, dass Ihr Code funktioniert (und was ist besser als eine ausführbare Spezifikation in Form eines Tests?), Funktioniert er nicht .

Das gibt mir:

• Seelenfrieden: Mein CI-Server teilt mir mit, dass meine gesamte Codebasis funktioniert.
• Die Fähigkeit, meinen Code zu verbessern: Ich kann meinen Code umstrukturieren - umgestalten - in dem Wissen, dass ich nach der Umstrukturierung nichts kaputt gemacht habe.

Unit Testing ist eine Disziplin. Da Code nicht unbedingt funktionieren muss, wird er häufig verworfen.

Es ist jedoch eine bewährte Methode, die zu robustem und weniger fehlerbehaftetem Code führt. Ich glaube nicht, dass ich Ihnen die Vorteile erklären muss, wie Sie bereits erwähnt haben. Wenn Sie sich einige der führenden Open-Source-Projekte ansehen, unabhängig davon, ob es sich um Javascript-Bibliotheken, Full-Stack-Frameworks oder Einzweckanwendungen handelt, verwenden sie alle Unit-Tests.

Ich vermute, dass Ihre Kollegen, die davon abraten, es zu verwenden, keine Programmierer sind. Wenn ja, sagen wir einfach, dass es nicht viele Menschen gibt, die ich höher schätze als Menschen wie Martin Fowler oder Kent Beck ;).

Wie bei den meisten Best Practices handelt es sich um langfristige Vorteile, in die Sie einige Zeit investieren müssen. Sie könnten ein langes Skript mit prozeduralem Code schreiben, aber wir alle wissen, dass Sie sich gewünscht haben, dass Sie ihn objektorientiert geschrieben hätten, wenn Sie ihn nach zwei Jahren überarbeiten müssen.

Gleiches gilt für Unit-Tests. Wenn Sie in Ihrer Anwendung Komponententests für kritische Teile schreiben, können Sie sicherstellen, dass diese auch nach dem Refactoring des Codes immer wie vorgesehen funktionieren. Vielleicht codieren Sie so gut, dass Sie nie einen Regressionsfehler haben. Wenn Sie dies jedoch nicht tun oder ein neuer Programmierer in Ihr Team aufgenommen wird, möchten Sie sicherstellen, dass die Fehler der Vergangenheit nicht erneut auftreten. Ich denke, Ihr Chef würde sich auch darüber freuen, anstatt einen Fehlerbericht einreichen zu müssen, den er vor einem halben Jahr für behoben hielt.

Unit-Tests erfordern eine Unit-Test-freundliche Sprache, ein Unit-Test-freundliches Design und ein Unit-Test-freundliches Problem.

C ++, Multithread-Design und GUI werden ein Albtraum sein, und die Problemabdeckung wird entsetzlich sein.

.NET, wiederverwendbare Single-Threaded-DLL-Assembly, reine Rechenlogik wird ein Kinderspiel.

Lohnt es sich, kann ich nicht wirklich sagen.

Refactorst du viel? Sehen Sie in Ihrem Code häufig "dumme Bugs" wie "off by one"?

Was auch immer Sie tun, seien Sie nicht der Typ, der andere kritisiert, indem er sagt "Sie haben keine Unit-Tests, deshalb saugen Sie". Wenn Ihnen Tests helfen, versuchen Sie es, wenn nicht, ist es nicht so, als wären sie eine Silberkugel.

Ich möchte , aber ich hatte das Pech, fast ausschließlich in Unternehmen zu arbeiten, die sich einfach nicht um Qualität kümmern und sich mehr darauf konzentrieren, Müll zusammenzuwerfen, der ein bisschen irgendwie funktioniert, wenn man blinzelt. Ich habe Unit-Tests erwähnt und bekomme ein "Huh?" Art von Look (der gleiche Look, den ich erhalte, wenn ich die SOLID- Prinzipien oder ORMs oder Entwurfsmuster erwähne, die jenseits der "Klasse mit allen statischen Methoden" liegen oder die .NET-Namenskonventionen befolgen). Ich war bisher nur in einem Unternehmen, das diese Dinge verstand, und leider war es ein kurzfristiger Vertrag, und die Abteilung wurde auf Kostensenkungen reduziert, sodass nicht genügend Zeit zum Lernen vorhanden war.

Ich habe Unit-Tests in weggeworfenen Dummy-Projekten absolviert, aber ich habe mich noch nicht wirklich mit ausgewachsenem TDD / BDD beschäftigt, und kein Mentor, der mir dabei helfen kann, erschwert die ordnungsgemäße Durchführung erheblich.

Wir benutzen sie. Ein großer Vorteil ist die Überprüfung des Unit-Test-Frameworks auf Speicherlecks und Zuordnungsfehler . Manchmal liegt das Problem im Komponententestcode selbst, oft aber auch im Produktionscode.

Es ist eine großartige Möglichkeit, die Dinge zu finden, die bei einer Codeüberprüfung übersehen werden.

Unit-Tests (sollten) laufen auch sehr schnell und können im Rahmen Ihrer kontinuierlichen Integration nach jedem Commit und auch von Entwicklern vor dem Commit ausgeführt werden. Wir haben über 1.000, deren Ausführung weniger als 20 Sekunden dauert.

Vergleichen Sie mit über 40 Minuten für Automatisierungstests auf Systemebene und Stunden / Tage für manuelle Tests. Natürlich sind Unit - Tests nicht nur die Prüfung sollten Sie sie können diese Fehler zu finden und testen Sie tun, aber zu einem feinkörnig Code-Ebene werden helfen Grenzfälle , dass das System / Integrationstests nicht berühren können. Unser Code muss mit einer Entscheidungsabdeckung von über 75% und einer Funktionsabdeckung von 100% getestet werden, was ohne Unit-Tests sehr schwer zu erreichen wäre.

Ich würde sagen, dass Unit-Tests einen Mehrwert bieten, aber ich bin kein großer TDD-Schüler. Ich finde den größten Nutzen mit Unit-Tests, wenn ich Motoren oder irgendeine Art von Motor wirklich und dann Utility-Klassen berechne, Unit-Tests sind dann sehr hilfreich.

Ich bevorzuge automatisierte Integrationstests für die mehr datenabhängigen Blöcke, aber es kommt darauf an, dass ich im Datengeschäft tätig bin. Viele Fehler betreffen mehr Daten in unserer Umgebung als alles andere, und daher funktionieren die automatisierten Integrationstests gut. Überprüfen der Daten vor und nach diesen Tests und Generieren von Ausnahmereports aus diesen Tests.

Unit-Tests bieten also einen echten Mehrwert, insbesondere wenn das zu testende Gerät mit allen erforderlichen Eingängen ausgestattet werden kann und mit den angegebenen Eingängen allein arbeitet. Auch in meinem Fall sind die Calc-Engines und Utility-Klassen perfekte Beispiele dafür.

Kosten: Code langsamer, Lernkurve, Entwicklerträgheit

Vorteile: Im Allgemeinen habe ich festgestellt, dass ich beim ersten Testen besseren Code geschrieben habe - SOLID weise ...

Aber meiner Meinung nach liegt der größte Vorteil der IMHO in der Zuverlässigkeit größerer Systeme, die sich häufig ändern. Ein guter Unit-Test erspart Ihnen (meiner) Ärger, wenn Sie mehrere Versionen veröffentlichen, und kann einen großen Teil der mit manuellen QS-Prozessen verbundenen Kosten einsparen. Natürlich wird kein fehlerfreier Code garantiert, aber es werden einige schwer vorhersehbare gefunden. In großen komplexen Systemen kann dies in der Tat ein sehr großer Vorteil sein.

Ich mache einen Unit-Test bei der Arbeit, wenn ich die Gelegenheit dazu bekomme, und ich versuche, meine Kollegen davon zu überzeugen, dasselbe zu tun.

Ich bin nicht religiös, aber die Erfahrung zeigt, dass Nutzungs- und Geschäftsmethoden, bei denen es sich um Unit-Tests handelte, sehr robust sind und in der Testphase in der Regel nur wenige oder gar keine Fehler auftreten, was letztendlich die Projektkosten senkt.

Wo ich den wahren Vorteil des Codierens von Unit Tests und der Ausführung von Unit Tests als Teil des täglichen Build-Prozesses sah, arbeitete ich an einem Projekt mit über 30 Entwicklern auf drei verschiedenen Kontinenten. Bei den Unit-Tests hat sich herausgestellt, dass jemand eine Klasse, die er beibehalten hat, auf subtile Weise geändert hat, ohne zu verstehen, wie die Leute diese Klasse verwendeten. Anstatt darauf zu warten, dass der Code die Testgruppe erreicht, gab es sofort eine Rückmeldung, als die Unit-Tests anderer Leute infolge der Änderung fehlschlugen. [Deshalb müssen alle Komponententests routinemäßig ausgeführt werden, nicht nur die, die Sie für Ihren Code geschrieben haben.]

Meine Richtlinien für Unit-Tests sind:

1. Testen Sie alle Bedingungen, die Ihnen für Ihren Code einfallen, einschließlich fehlerhafter Eingaben, Grenzen usw.
2. Alle Unit Tests für alle Module sollten regelmäßig durchgeführt werden (dh als Teil der nächtlichen Builds)
3. Überprüfen Sie die Unit-Testergebnisse!
4. Wenn jemand einen Fehler in Ihrem Code findet, der Ihre Tests überstanden hat, schreiben Sie einen neuen Test dafür!

Ich habe kürzlich TDD gelernt und finde, dass es sehr nützlich ist. Es gibt mehr Sicherheit, dass sich mein Code so verhält, wie ich es erwartet habe. Zusammen mit dem Vornehmen von Re-Factoring, das ich einfacher machen möchte. Immer wenn ein Fehler gefunden wird, können Sie durch das Testen sicherstellen, dass er nicht wieder angezeigt wird.

Am schwierigsten ist es, gute Komponententests zu schreiben .

Es ist ein guter Maßstab für Ihren Code.