Ist es als professioneller Entwickler akzeptabel, keine Komponententests zu schreiben? [geschlossen]

Fragen Sie sich nur nach den Vor- und Nachteilen von TDD / automatisierten Unit-Tests und suchen Sie nach der Ansicht der Community, ob es für professionelle Entwickler akzeptabel ist, Anwendungen zu schreiben, ohne Unit-Tests zu unterstützen?

Um was zu testen?

Wenn Sie von einer 100% igen Codeabdeckung sprechen, ist dies äußerst selten, nicht nützlich und oft unmöglich. Auf die gleiche Weise ist das Testen von CRUD-bezogenem Code Zeitverschwendung, und es wäre höchst unprofessionell, Stunden damit zu verbringen, Code zu schreiben, den Sie nicht benötigen, anstatt etwas wirklich Nützliches zu tun.

Als Entwickler müssen Sie nun wissen, wie man Unit-Tests schreibt und wo Sie sie benötigen.

Theorie

Es gibt ein weit verbreitetes Missverständnis, dass Unit-Tests zum Testen von "Einheiten" dienen .
Unit-Tests, ebenso wie alle anderen Tests, testen die Funktionalität . Es kann einfach nichts anderes getestet werden.

Die Funktionalität eines komplexen Systems kann jedoch häufig nicht effektiv getestet werden.
Angenommen, ein Benutzer drückt die Schaltfläche "Löschen", und es passiert nichts. Warum? Möglicherweise liegt ein Fehler in einer Datenbank vor, eine Verbindung ist möglicherweise unterbrochen, eine Kernlogik ist möglicherweise fehlerhaft oder sogar eine Operation ist erfolgreich, aber die Schnittstelle wurde nicht ordnungsgemäß aktualisiert. Jede Schicht kann viele Funktionen enthalten, die sich gegenseitig aufrufen, und es ist nicht immer klar, wo der Fehler liegt.
Unit-Tests basieren auf einem Paradigma , Komponenten zu trennen und einzeln zu testen.

Dies garantiert nicht, dass das gesamte System funktioniert, vereinfacht jedoch das Testen.

TDD ist an sich keine Anforderung. Es vereinfacht das Codieren, indem ein Entwickler gezwungen wird, zuerst zu antworten: "Was werde ich eigentlich codieren?".

Kosten

Viele denken, dass sie ihre Zeit sparen, wenn sie keine Tests schreiben. Falsch. Strategisch betrachtet steigen die Kosten eines Fehlers seit dem Auftreten bis zur Erkennung exponentiell mit der Zeit .

Angenommen, Sie machen einen Fehler in Ihrem Code und erkennen und beheben ihn am selben Tag. Die Kosten sind $ X .
Nehmen wir an, der Fehler bleibt unentdeckt und wird wöchentlich intern erstellt. Glücklicherweise hat die Qualitätssicherung es erkannt, einen Fehler im Bug-Tracker ausgelöst, das Problem war Gegenstand einer 5-minütigen Diskussion über ein Meeting mit 5 Personen usw. Schließlich beheben Sie es. Die Kosten sind die Summe der von allen aufgewendeten Arbeitskräfte und können in diesem Fall 3 * X $ betragen.
Was ist, wenn der Fehler beim Betatest aufgetreten ist und mehr Personen involviert sind? Lassen Sie uns sagen, $ 10 * X .
Wenn es für lange Zeit unentdeckt bleibt, an 1.000 Kunden ging (hoffentlich nicht an eine Million!), 10 von ihnen es entdeckten, führten sie eine Diskussion mit Ihren Support-Mitarbeitern, einige riefen möglicherweise Ihren Chef an, Ihre Teamkollegen versuchen, es zu reproduzieren , etc, etc. Schließlich kommt der Fehler zu Ihnen zurück und Sie beheben ihn. Wie viel insgesamt? Nun mehr als $ 50 * X .

Wie Sie sehen, wird ein Fehler früher oder später zu Ihnen (oder Ihrem Kollegen) zurückkehren. Der einzige Unterschied ist, wann es passiert und wie viel es kosten würde.
Unit-Tests verkürzen den Lebenszyklus von Fehlern und senken somit die Kosten.

Profis

• Mit Unit-Tests kann der Entwickler besser codieren . So einfach ist das.
• Sie lassen Ihre Zeit sparen;
• Sie senken die Kosten;
• Unit-Tests leben zusammen mit dem Code, den sie testen. Bei jeder Änderungsanforderung (die immer auftritt) werden die Tests angepasst.

Con's

Ich kann eine einzige Ausrede sehen, keine Tests zu schreiben. Wenn Sie einen Prototyp schreiben, z. B. etwas, das niemals an die anderen Personen geht. Oder vielleicht schreiben Sie etwas für den einmaligen Gebrauch.

Sicher, ist es akzeptabel , nicht schreiben Unit - Tests für kleinen internen Helfer Dienstprogramme oder Test - Tools oder Szenarien , in denen Unternehmen wirklich wirklich andere Dinge als Qualität brauchen und Sie als professionellen Entwickler feststellen , dass Sie die Software erledigen und arbeiten genauso schnell ohne.

Nach meiner Erfahrung stammen 95% der Fehler, die durch Komponententests abgefangen werden können, aus Aufrufen der Datenschicht, insbesondere nach Änderungen des Datenbankdesigns. Wenn Sie eine Datenbank verwenden, testen Sie einfach jede Methode, mit der Sie darauf zugreifen. Die Tests müssen nicht einmal aufwendig sein, sondern nur die Überprüfung der Gesundheit.

Als Antwort auf Ihre Frage: Wenn Sie auf eine Datenbank zugreifen und ein professioneller Entwickler sind, sollten Sie Komponententests verwenden. Ansonsten kommt es darauf an.

Es hängt wirklich davon ab, wie die Anwendung verwendet wird. Ist dies eine geschäftskritische Anwendung? Oder handelt es sich um eine einfache Verifizierungsanwendung, die nur intern von Entwicklern verwendet wird? Bei der Arbeit an den Kernanwendungen für Ihr Unternehmen sollten so viele Komponententests wie nötig durchgeführt werden, um sicherzustellen, dass die Geschäftsentscheidungen abgedeckt sind. Abhängig von Ihrem Unternehmen sind dies die Anwendungen, die Kunden sehen, und Fehler können das Geld kosten. Wenn dies gut gemacht wurde, können Komponententests eine große Hilfe sein, um sicherzustellen, dass Ihre Anwendungen bei der Bereitstellung funktionieren. Aber es ist kein Allheilmittel und es sollten noch menschliche Tests durchgeführt werden. Einfache interne (oder zusätzliche) Anwendungen benötigen keine Komponententests, sollten aber dennoch gut geschrieben sein.

Bei TDD geht es nicht nur darum, zuerst Tests zu schreiben. Es geht darum sicherzustellen, dass Ihr Code leicht testbar ist. Und meistens ist leicht testbarer Code auch leichter zu lesen / zu debuggen / zu warten. Meistens folgt leicht testbarer Code auch Mustern und OO-Prinzipien wie SOLID. Ich würde als professioneller Entwickler argumentieren, dass Ihr Code immer so geschrieben sein sollte.

Sie wollen definitiv nicht "keine Tests". Wenn Sie Komponententests schreiben, können Sie zumindest sicher sein, dass Ihr Code Ihren Tests entspricht (obwohl Sie sicherstellen müssen, dass Ihre Tests Ihren Spezifikationen entsprechen).

Sie sind jedoch noch nicht fertig, wenn Sie nur Unit-Tests haben. Sie müssen wahrscheinlich noch Integrationstests und End-to-End-Tests durchführen (und im Laufe der Zeit Testfälle sammeln, um Fehlerregressionen abzufangen).

Ich werde hier auf die Nerven gehen und sagen, dass es meistens subjektiv ist und von Ihren Zielen abhängt. tl; dnr: Es ist gut zu tun, aber dogmatisch zu sein, wird einfach zu mehr Problemen führen.

TDD / Unit-Tests verbessern die Stabilität Ihres Codes. Sie erleichtern das Vornehmen von Änderungen, ohne die Codebasis wirklich gut zu kennen. Mit ihnen können Sie schneller umgestalten. Sie können sicher sein, dass Sie nichts Dummes tun. Unit-Tests können auch Zeitverschwendung sein. Zeit, die für das Schreiben von Code aufgewendet werden könnte. Sie können sich auch täuschen lassen, dass Ihr Code funktioniert, wenn dies nicht der Fall ist, wenn Sie ihnen blind folgen.

Wenn Sie für ein Unternehmen arbeiten, das Best Practices unterstützt und Ihnen die Zeit gibt, diese zu implementieren, und eine Anwendung suchen, die lange hält, ist es für jeden am besten, Komponententests und Codeüberprüfungen zu verwenden und zu üben. Ein QA-Team kann ein akzeptabler Ersatz sein, wenn die Entwickler es nicht missbrauchen. Wenn Sie einen Prototyp schreiben (sogar einen Serienprototyp), ist dies möglicherweise schneller, wenn Sie nur Rauchtests durchführen.

Wenn Sie an etwas arbeiten, bei dem ein Durcheinander nicht das Ende der Welt bedeuten wird, ist eine geringere Berichterstattung wahrscheinlich in Ordnung. Finanztransaktionen? Viele. Wenn Sie ein Team starker Entwickler haben, die die Codebasis kennen, gut zusammenarbeiten und keinen Umsatz erzielen, benötigen Sie wahrscheinlich weniger Abdeckung. Etc.

Also wird es wahrscheinlich eine Funktion von sein

• Teamgröße / Umsatz
• Gewünschte Haltbarkeit der Anwendung
• Die Anwendung und wie kritisch Fehler sind
• Zeit für die Implementierung der Best Practices in Bezug auf den Entwicklungsplan
• Teamfähigkeit (dies bedeutet nicht, ein guter Programmierer zu sein, dass Sie keine Komponententests schreiben sollten, aber ein Team ohne Nachwuchsentwickler kann möglicherweise mit mehr Erfolg am Sitz der Hose vorbeifliegen)

Es gibt viele Situationen, in denen es akzeptabel wäre, keine Unit-Tests zu schreiben. TDD ist gerade "in", aber es ist keine Silberkugel.

Es ist professionell, wartbare Unit-Tests zu schreiben, die Ihnen Zeit und Tränen sparen!

Es gibt eine misconception that Unit test finds bugs. Nun, das gilt einfach NICHT für alle Fälle. Beim Unit-Test geht es nicht darum, Fehler zu finden oder Regressionen zu erkennen. Es ist per Definition examine each unit of your code separately. Wenn Ihre Anwendung jedoch real ausgeführt wird, müssen alle diese Einheiten zusammenarbeiten, und das Ganze ist komplexer und subtiler als die Summe der unabhängig getesteten Teile.

Daher besteht das Ziel des Unit-Tests (innerhalb des TDD-Prozesses) darin, Softwarekomponenten robust zu entwerfen.

Bearbeiten: Es gibt eine Ausnahme, bei der Unit-Tests tatsächlich Fehler erkennen. Dies geschieht, wenn Sie den Code einer Einheit umgestalten oder umstrukturieren, ohne jedoch das Verhalten ändern zu wollen. In diesem Fall können Unit-Tests häufig feststellen, ob sich das Verhalten des Geräts geändert hat.

Ist es als professioneller Entwickler akzeptabel, keine Komponententests zu schreiben?

Nein.

Ohne Frage - Dies sollte eine der ersten Lektionen sein, die ein Frischer lernt. Sie müssen Komponententests entwickeln, um zu beweisen, dass Ihr Code funktioniert, bevor Sie der Qualitätssicherung mitteilen, dass Ihr Code zum Testen bereit ist. Andernfalls würden die Kosten für das Projekt steigen und die Moral des Teams sinken.

Wie gründlich sollten diese Unit-Tests sein?

Hier ist der Lackmustest: Wenn die Qualitätssicherung einen Fehler in Ihrem Code entdeckt, können Sie dann mit Ihren Unit-Tests Ihrem Chef Ihre Sorgfaltspflicht beweisen?

Wenn Ihre Antwort "Nein" lautet, sollten Sie einen besseren Komponententest (oder bessere Tests) erstellen.
Wenn Ihre Antwort "Ja" lautet, ist Ihr Code zur Überprüfung bereit.

Ist es als professioneller Entwickler akzeptabel, keine automatisierten Komponententests zu schreiben ?

Ja.

Insbesondere wenn der Zeit- und Arbeitsaufwand für das Schreiben automatisierter Komponententests den durch den Test erzielten Nutzen überwiegen würde. Dies umfasst, ohne darauf beschränkt zu sein, UI-Code, der möglicherweise schwer zu verspotten ist.

Betonung: Ich sage nicht , dass es unmöglich ist, automatisierte Komponententests für UI-Code zu schreiben. Ich sage nur, dass es meiner Erfahrung nach manchmal schwierig ist, automatisierte Komponententests für einen UI-Code zu schreiben .