Mir wurde eine Aufgabe zugewiesen, die meiner Meinung nach keinen Sinn ergibt. Soll ich meinen Chef darauf ansprechen?

Im Allgemeinen ist es besser, wenn Unit-Tests vor oder mit dem in Entwicklung befindlichen Code geschrieben werden. Das bedeutet aber nicht, dass im Nachhinein geschriebene Unit-Tests nutzlos sind – und sie sind sicherlich besser als gar keine Unit-Tests.

Unit-Tests, die nach dem Code geschrieben werden, können zwei Dinge erreichen:

1. Möglicherweise finden Sie Umstände, die Ihnen vorher nicht bewusst waren, unter denen der Code fehlschlägt. Dies ist nützlich zu wissen und bedeutet, dass Sie es beheben können, bevor der Code ausgeliefert wird.
2. Gute Unit-Tests können nach jeder Änderung am Code wiederholt ausgeführt werden, um zu überprüfen, ob die Änderungen nichts beschädigt haben. Dies wird als „Regressionstest“ bezeichnet.

Während Ihr Chef vielleicht (vielleicht!) früher eine weniger als ideale Entscheidung getroffen hat, trifft er jetzt die richtige Entscheidung.

Machen Sie also weiter und schreiben Sie die Unit-Tests, die Ihnen zugewiesen wurden. Wenn Sie das nächste Projekt starten, schlagen Sie Ihrem Chef vor, dass Sie mit dem Schreiben der Tests beginnen. Und lesen Sie mehr über "Test Driven Development", was daraus wird, wenn Sie es richtig machen.

Ich denke, die eigentliche Frage hier ist in der letzten Zeile:

Soll ich meinen Chef auf eine mir übertragene Aufgabe ansprechen, die ich für nicht sinnvoll halte? Und wenn ja, wie?

Die Antwort ist ein klares JA , Sie sollten sich an Ihren Chef wenden. Eines von mehreren Dingen könnte passieren:

• Sie haben die Chefin völlig falsch verstanden und denken, sie will, dass Sie etwas anderes tun, als sie eigentlich will. Wenn Sie nicht fragen, verschwenden Sie viel Zeit damit, das Falsche zu tun.
• Sie kennen die Gründe für die Anfrage nicht. In der realen Welt machen wir manchmal dummes Zeug, um eine Anforderung zu erfüllen, die keinen wirklichen Sinn ergibt. Dies kommt häufig vor, wenn es um Zertifizierungen geht – es kann sein, dass Sie wissen, dass ein Schritt nutzlos ist, aber Sie können den Prozess aus verschiedenen Gründen im Moment nicht ändern.
• Sie haben vielleicht nicht genug Erfahrung, um zu verstehen, warum dies an dieser Stelle getan werden sollte. Der Chef kann es erklären und Sie werden etwas lernen.
• Sie haben tatsächlich ein Problem mit dem gefunden, was der Chef will. Der Chef hat jetzt die Möglichkeit, die Richtung zu ändern, bevor er einen Haufen Ihrer Arbeitsstunden mit nutzloser Arbeit verschwendet.

Egal um welchen es sich handelt, im Gespräch mit dem Chef erhalten Sie die Informationen, die Sie benötigen, um fortzufahren.

Ich würde mit etwas wie gehen

Ähm, Boss, das scheint mir keinen Sinn zu ergeben. Es sieht so aus, als wäre diese Arbeit nutzlos oder sogar kontraproduktiv, also glaube ich, dass ich etwas falsch verstanden habe.

Das versetzt Sie in die Lage, um Hilfe zu bitten, anstatt Ihrem Chef zu sagen, dass sie falsch liegt. Es beginnt ein Gespräch, kein Streit, und liefert Ihnen die Informationen, die Sie benötigen.

Ein wichtiger Punkt hier, den ich für erwähnenswert halte, ist folgender:

Ich habe das Gefühl, dass die mir zugewiesene Aufgabe falsch ist.

Meiner Meinung nach lohnt es sich, sich vor der eigentlichen Arbeit etwas Zeit zu nehmen und die Perspektive auf die Arbeit anzupassen.

Also, wenn ich es richtig verstanden habe, finden Sie das Schreiben von Komponententests nach dem Code falsch, weil „das Buch“ sagt, dass sie zuerst geschrieben werden sollten. Wie bei jeder anderen in Stein gemeißelten Regel ist es gut zu verstehen, was dahinter steht. In diesem Fall besteht einer der Vorteile davon, zuerst Tests geschrieben zu haben, darin, dass es Sie anleitet, Ihr Modul/Ihre Klasse/Funktion auf eine Weise zu erstellen, die für den Client-Code einfach und intuitiv zu verwenden ist: Code, der es verwendet. Tatsächlich sind Tests der erste Client Ihres Codes.

Worauf ich hinaus will, ist, dass selbst wenn der Code nicht als Test-First geschrieben wurde, es Ihnen trotzdem zugute kommt, Tests zu schreiben: Wenn es passieren wird, dass der Code schwer zu testen oder umständlich zu verwenden ist, werden Sie ihn nie brauchen eine weitere theoretische Erklärung nach dem Buch, warum es gut ist, zuerst Tests schreiben zu lassen.

Ich meine, wenn Sie jetzt Tests schreiben, haben Sie die Möglichkeit, Ihren Code zu bewerten und Wege zu finden, ihn zu verbessern. Und auch wenn Sie dieses Mal nicht sofort einsteigen und es verbessern können, werden Sie es beim nächsten Mal tun: weil Sie bereits wissen, warum.

Also, was ich tun würde, ist Folgendes: Ich würde es einfach versuchen. Nur als Experiment, nur als lustige Code-Kata-ähnliche Übung. Seien Sie bereit, um ein wenig Hilfe zu bitten, wenn der Anfang schwierig ist. Aber Sie können sicher sein, dass dies Ihnen helfen wird, Ihren Code auf neue Weise zu verstehen, und ich wette, dass sich das Schreiben von Tests – egal ob davor oder danach – als ein Trick entpuppen wird, den Sie in Ihrer Nähe behalten sollten.

Viel Glück!

Es ist wahr, dass Unit-Tests im Vorfeld viele Vorteile haben. Die Realität der Softwareentwicklung beinhaltet jedoch oft Dinge, die alles andere als ideal sind.

Erstens arbeitet man mit Menschen und Menschen machen Fehler. Manchmal werden suboptimale Entscheidungen getroffen, und manchmal werden Tests vergessen.

Zweitens gibt es konkurrierende Prioritäten für jedes Projekt. Verfügbare Zeit zum Erstellen des Produkts: Qualität des Produkts (und damit Testen des Produkts), verfügbare Ressourcen zum Erstellen des Produkts und für das Produkt erforderliche Funktionen. Der Code, den Sie testen sollen, könnte geschrieben worden sein, als nicht genug Zeit war, um alle Funktionen perfekt zu integrieren, also wurden sie mit geringerer Qualität erstellt.

Drittens ist dies möglicherweise einfach nicht der Prozess in Ihrem Unternehmen. Die Version des Softwareentwicklungslebenszyklus Ihres Unternehmens kann ausdrücklich alle Tests an das Ende des Projekts stellen.

Am wichtigsten ist, dass Sie erst seit 1 Jahr in Ihrem Job sind. Sie müssen mit Ihrem Mentor, Teamleiter und Vorgesetzten zusammenarbeiten, um zu lernen, wie die Dinge dort gemacht werden. Wenn Sie Fragen haben wie: "Warum wurde das nicht während der Entwicklung gemacht?" dann sollten Sie jemanden in Ihrem Unternehmen bitten, Ihnen zu helfen, den Entwicklungsprozess besser zu verstehen. Wir im Internet können Ihnen nicht sagen, warum in Ihrem Unternehmen eine Entscheidung getroffen wurde.

Die einfache Antwort lautet: Obwohl es sehr spät im Prozess ist, über Tests nachzudenken, sollten Sie sie durchführen, wenn Sie die Zeit haben, da sie Ihrer Entwicklung zugute kommen.

In Bezug auf Fehler sollten Sie im Rahmen des Prozesses auch Tests erstellen/hinzufügen. Dadurch wird auch sichergestellt, dass spätere Arbeiten die Korrekturen nicht rückgängig machen.

Jedes Mal, wenn Ihnen eine Aufgabe unklar ist oder warum sie erledigt werden muss, müssen Sie dies mit Ihrem Chef besprechen. Was Sie jedoch nicht tun wollen, ist undiplomatisch zu fragen. Sagen Sie also nicht, warum ich gebeten werde, diese nutzlosen Tests zu schreiben. Sagen Sie, dass Ihnen die Aufgabe auf keinen Fall klar ist. Zu sagen, dass die Aufgabe Ihnen nie lächerlich vorkommt, ist es nie. Eine der entscheidenden Fähigkeiten, die es zu lernen gilt, ist, wie man Leitfragen stellt, um einem Chef klar zu machen, dass Sie Bedenken bezüglich eines Problems haben, ohne sich zu äußern und zu sagen, dass Sie den Chef für dumm halten.

Fragen Sie, was genau er von diesen Tests zu diesem Zeitpunkt der Entwicklung erwartet. Fragen Sie, was Sie tun sollen, wenn einige der Tests fehlschlagen. Fragen Sie, welche Arten von Fehlern dazu führen würden, dass das Produkt verzögert werden müsste und welche als Fehler dokumentiert werden müssten, die später behoben werden müssen. Fragen Sie, ob Sie dies als Teil aller Entwicklungen in Zukunft tun sollten. Fragen Sie, ob es Beispieltests aus einem anderen Projekt gibt. Fragen Sie, welche Bereiche Sie priorisieren sollten, wenn Sie in der vorgegebenen Zeit nicht die gesamte Codebasis abdecken können. Es ist besser, 5 gute Tests zu haben, die den kritischsten und komplexesten Teil der Anwendung abdecken, als 100 Tests, die die unkritischen, aber leicht verständlichen Dinge abdecken.

Nachdem Sie die Tests geschrieben haben, können Sie vorschlagen, dass eine testgetriebene Entwicklung eine bessere Idee gewesen wäre, insbesondere wenn Sie zu diesem Zeitpunkt erhebliche Probleme mit dem Code feststellen.

Nun, ich kann mir mehrere Gründe vorstellen, dies an dieser Stelle zu tun. Vielleicht sollte jemand die Tests schreiben und hat es nicht getan und braucht sie aus rechtlichen Gründen. Vielleicht war früher keine Zeit, den Test zu schreiben, aber der Chef möchte, dass Sie sich mit dem Code vertraut machen, also hat er Sie gebeten, dies als Trainingsübung zu tun. Vielleicht hat er keine wichtige Entwicklungsaufgabe für Sie und das Schreiben von Tests ist eine Möglichkeit, produktive Arbeit von Ihnen zu bekommen.

Theoretisch können Sie durch das Schreiben von Testfällen parallel zur Entwicklung besseren Code schreiben. In vielen Fällen funktioniert dies jedoch möglicherweise nicht (hauptsächlich aufgrund der Zeitbandbreite).

Das Wichtigste zuerst: Das Schreiben von Unit-Testfällen (selbst nach der Entwicklung) ist keine nutzlose Aktivität. Bitte teilen Sie dies Ihrem Vorgesetzten nicht mit und entwickeln Sie bei ihm/ihr ein falsches Bild von sich. Verstehen Sie, dass Unit-Testfälle nicht nur für Sie hilfreich sind, sondern auch für andere, die in Zukunft möglicherweise an demselben Modul arbeiten. Im Folgenden sind die Gründe für das Schreiben eines Testfalls aufgeführt:

• Gut geschriebene Testfälle fungieren als Wächter des Codes. dh nehmen Sie an, Sie haben eine spezifische if-else-Klausel geschrieben, um ein Eckszenario zu handhaben. Wenn morgen jemand neu hinzukommt und entscheidet, dass diese if-else-Klausel nutzlos ist und abgeschafft werden muss (vielleicht kennt er das Eckszenario nicht). Wie schützen Sie diesen Code? Schreiben Sie einen Testfall, um das Szenario zu erfassen. Auf diese Weise schlägt er fehl, wenn er den Testfall ausführt, und gibt einen Hinweis auf den Grund für den Code.
• Mit Testfällen können Sie verschiedene Szenarien überwachen, die beim manuellen Testen möglicherweise nicht erfasst werden. Testfälle ermöglichen eine enorme Bandbreite in Bezug auf die Daten, die Sie übergeben können, und die Ausgabe, die Sie erwarten können. Auf diese Weise können Sie als Entwickler eine Vielzahl von Szenarien erfassen, die Ihnen mehr Vertrauen in Ihren Code geben.
• Durch das Ausführen von Testfällen nach jeder Codeänderung können Regressionsfehler erkannt werden (Oft würde Ihr eigener Fix dazu führen, dass Ihr eigener Code kaputt geht!).

Alles in allem hängt es davon ab, wie gewissenhaft die Entwickler den Testfallläufen folgen und wie effizient der Testfall geschrieben wird. Aber untergraben Sie bitte nicht die Aufgabe, Testfälle zu schreiben.

Bei neuen Projekten ist es aus verschiedenen Gründen üblich, dass mehr Tests später als parallel zur Entwicklung geschrieben werden:

1) Wenn es sich um ein großes Produkt handelt, möchten Sie im Allgemeinen frühzeitig Fortschritte bei den harten Architekturstücken erzielen. Nehmen wir an, es dauert 1 Monat, um Modul A zu schreiben, 1, um Modul B zu schreiben, und 2 Wochen für jedes Modul, um Tests zu schreiben. Dann bindest du alles zusammen. Wenn Sie warten, bis Sie die Tests zuerst durchgeführt haben, können Sie diese Probleme erst nach 3 Monaten finden. Wenn Sie weniger Tests parallel durchführen und die Entwicklung vorab laden, können Sie die Designprobleme (deren Behebung am meisten kostet) einen Monat finden vorhin.

2) Die Geschäftsrealität erlaubt es Ihnen selten, alle Tests, die Sie letztendlich benötigen, parallel zu schreiben.

3) Wenn das Projekt nicht trivial ist, wissen Sie wahrscheinlich nicht genau, wie Sie alles machen werden. Stücke werden geschrieben, dann überarbeitet oder sogar ersetzt. (Ich arbeite jetzt an einem 9-monatigen neuen Projekt, wir haben die Datenbank bereits ersetzt. Ich habe gerade den Image-Cache komplett neu geschrieben, weil die Art und Weise, wie die Netzwerkbibliothek mit dem Threading umgegangen ist, zu viele Durchgänge zum UI-Thread verursacht hat, was Leistungsprobleme verursacht hat. Alle Tests laufen beide hätten von Grund auf neu geschrieben werden müssen). Wenn Sie viel mit dem Schreiben von Krawattentests verbringen, müssen Sie viel Zeit mit dem Umschreiben und Korrigieren von Tests verbringen. Es macht keinen Sinn, Tests zu schreiben, bis die Dinge zumindest halbstabil sind.

4) Selbst wenn Sie Dinge parallel schreiben, werden Sie Dinge verpassen. Komponententests sind nie abgeschlossen, sie entwickeln sich mit Ihrer App weiter. Sie fügen weitere hinzu, wenn Sie Eckfälle finden, die Sie übersehen haben (das ist auch der Grund, warum Einheitentests nicht beweisen, dass Ihr Code richtig ist – sie können höchstens beweisen, dass sie nicht falsch sind, auf eine Weise, die Sie testen wollten). Sie fügen nach der Entwicklung immer weitere Tests hinzu, wenn Sie diese finden.

5)Unit-Tests sind während der gesamten Lebensdauer des Projekts nützlich. Auch wenn es besser gewesen wäre, sie früher zu haben – es wird trotzdem helfen, voranzukommen. Sie jetzt zu schreiben ist besser als nichts.