Wie bringt man junge Programmierer dazu, Tests zu schreiben?[geschlossen]

https://stackoverflow.com/questions/7252

08-06-2019
|

Frage

Wir haben einen Junior-Programmierer, der einfach nicht genug Tests schreibt.
Ich muss ihn alle zwei Stunden nörgeln: „Hast du Tests geschrieben?“
Wir haben Folgendes versucht:

Zeigt, dass das Design einfacher wird
Das Vorzeigen verhindert Mängel
Es zu einer Ego-Sache machen, die besagt, dass nur schlechte Programmierer das nicht tun
Dieses Wochenende mussten zwei Teammitglieder zur Arbeit kommen, weil sein Code eine NULL-Referenz hatte und er ihn nicht getestet hatte

Meine Arbeit erfordert stabilen Code von höchster Qualität, und normalerweise versteht ihn jeder, und es besteht keine Notwendigkeit, Tests durchzusetzen.Wir wissen, dass wir ihn dazu bringen können, Tests zu schreiben, aber wir alle wissen, dass Tests nützlich sind, wenn man sie selbst schreibt.

Kennen Sie weitere Motivationen?

Lösung

Dies ist einer von die schwierigsten Dinge machen.Bringen Sie Ihre Leute dazu bekomme es.

Manchmal ist es eine der besten Möglichkeiten, Junior-Programmierern dabei zu helfen, es zu verstehen und von den Senioren die richtigen Techniken zu lernen, indem sie sich ein wenig mit der Paarprogrammierung befassen.

Versuche dies:Stellen Sie bei einem bevorstehenden Projekt den Junior-Mitarbeiter mit sich selbst oder einem anderen erfahrenen Programmierer zusammen.Sie sollten zusammenarbeiten und abwechselnd „Fahren“ (derjenige, der auf der Tastatur tippt) und „Coaching“ (dem Fahrer über die Schulter schauen und ihn während der Fahrt auf Vorschläge, Fehler usw. hinweisen).Es mag wie eine Verschwendung von Ressourcen erscheinen, aber Sie werden feststellen:

Dass diese Jungs zusammen viel schneller und von höherer Qualität Code produzieren können.
Wenn Ihr jüngerer Mann genug lernt, um „es zu verstehen“, und ein älterer Mann ihn auf den richtigen Weg weist (z. B.„Okay, bevor wir fortfahren, schreiben wir einen Test für diese Funktion.“) Die dafür aufgewendeten Ressourcen werden sich auf jeden Fall lohnen.

Vielleicht lasst das auch jemand aus eurer Gruppe geben Unit-Tests 101 Ich denke, dass die Präsentation von Kate Rhodes eine großartige Möglichkeit ist, die Leute für das Testen zu begeistern, wenn sie gut vermittelt wird.

Eine andere Sache, die Sie tun können, ist, Ihren Jr.Entwickler üben das Bowlingspiel Kata Dies wird ihnen helfen, testgetriebene Entwicklung zu erlernen.Es ist in Java, kann aber problemlos an jede andere Sprache angepasst werden.

Andere Tipps

Führen Sie vor jedem Commit eine Codeüberprüfung durch (auch wenn es sich um ein einminütiges „Ich habe diesen Variablennamen geändert“ handelt) und überprüfen Sie im Rahmen der Codeüberprüfung alle Komponententests.

Unterzeichnen Sie den Commit erst, wenn die Tests abgeschlossen sind.

(Außerdem – Wenn seine Arbeit nicht getestet wurde – warum war sie dann überhaupt in einer Produktionsversion?Wenn es nicht getestet ist, lassen Sie es nicht rein, dann müssen Sie nicht am Wochenende arbeiten)

Ich selbst habe begonnen, darauf zu bestehen, dass jeder Fehler, den ich finde und behebe, als Test ausgedrückt wird:

„Hmmm, das stimmt nicht…“
Finden Sie ein mögliches Problem
Schreiben Sie einen Test und zeigen Sie, dass der Code fehlschlägt
Das Problem lösen
Zeigen Sie, dass der neue Code erfolgreich ist
Schleife, wenn das ursprüngliche Problem weiterhin besteht

Ich versuche dies sogar zu tun, während ich Sachen rausbringe, und ich bin ungefähr zur gleichen Zeit fertig, nur wenn bereits ein Teil der Testsuite vorhanden ist.

(Ich lebe nicht in einer kommerziellen Programmierumgebung und bin oft der einzige Programmierer, der an einem bestimmten Projekt arbeitet.)

Stellen Sie sich vor, ich wäre ein Scheinprogrammierer mit dem Namen ...Marco.Stellen Sie sich vor, ich habe vor nicht allzu langer Zeit meinen Schulabschluss gemacht und musste nie wirklich Tests schreiben.Stellen Sie sich vor, ich arbeite in einem Unternehmen, das dies nicht wirklich durchsetzt oder verlangt.OK?Gut!Stellen Sie sich nun vor, dass das Unternehmen auf den Einsatz von Tests umsteigt und versucht, mich damit in Einklang zu bringen.Ich werde auf die bisher erwähnten Punkte etwas bissig reagieren, als hätte ich dazu keine Nachforschungen angestellt.

Beginnen wir mit dem Ersteller:

Zeigt, dass das Design einfacher wird.

Wie kann mehr Schreiben die Dinge einfacher machen?Ich müsste jetzt im Auge behalten, ob ich mehr Fälle bekomme usw.Das macht es meiner Meinung nach komplizierter.Geben Sie mir solide Details.

Das Vorzeigen verhindert Mängel.

Ich weiß, dass.Deshalb werden sie Tests genannt.Mein Code ist gut und ich habe ihn auf Probleme überprüft, daher sehe ich nicht, wo diese Tests helfen würden.

Es zu einer Ego-Sache machen, die besagt, dass nur schlechte Programmierer das nicht tun.

Ohh, Sie denken also, ich sei ein schlechter Programmierer, nur weil ich nicht so oft Tests durchführe.Ich bin beleidigt und förmlich verärgert über dich.Ich hätte lieber Hilfe und Unterstützung als Sprüche.

@Justin Standard:Zu Beginn eines neuen Projekts vernetzen Sie den Junior-Mitarbeiter mit sich selbst oder einem anderen Senior-Programmierer.

Ohh, das ist so wichtig, dass Ressourcen aufgewendet werden, um sicherzustellen, dass ich sehe, wie die Dinge erledigt werden, und dass mir jemand dabei hilft, wie die Dinge erledigt werden.Das ist hilfreich, und vielleicht fange ich einfach damit an, es öfter zu tun.

@Justin Standard:Lesen Unit-Tests 101 Präsentation von Kate Rhodes.

Ahh, das war eine interessante Präsentation und hat mich zum Nachdenken über das Testen gebracht.Es hat einige Punkte angesprochen, die ich berücksichtigen sollte, und es hätte meine Ansichten vielleicht ein wenig beeinflussen können.

Ich würde gerne mehr überzeugende Artikel und andere Tools sehen, die mir dabei helfen, mich mit der Überzeugung vertraut zu machen, dass dies der richtige Weg ist, Dinge zu tun.

@Dominic Cooney:Nehmen Sie sich etwas Zeit und teilen Sie Testtechniken.

Ahh, das hilft mir zu verstehen, was von mir in Bezug auf Techniken erwartet wird, und es bringt mehr Dinge in meinen Wissensschatz, die ich vielleicht wieder verwenden kann.

@Dominic Cooney:Beantworten Sie Fragen, Beispiele und Bücher.

Es ist hilfreich, einen Ansprechpartner für die Beantwortung der Fragen zu haben. Das erhöht möglicherweise die Wahrscheinlichkeit, dass ich es versuche.Gute Beispiele sind großartig, und sie geben mir etwas, das ich anstreben kann, und etwas, nach dem ich als Referenz suchen kann.Bücher, die sich direkt darauf beziehen, sind gute Referenzen.

@Adam Hayle:Überraschungsrezension.

Sag was, du hast etwas ausgelöst, auf das ich völlig unvorbereitet bin.Ich fühle mich dabei unwohl, werde aber mein Bestes geben.Ich werde jetzt Angst haben und ein wenig Angst davor haben, dass das noch einmal zur Sprache kommt, danke.Allerdings hätte die Panikmache vielleicht funktioniert, aber sie hat ihren Preis.Wenn jedoch nichts anderes funktioniert, ist dies möglicherweise genau der nötige Anstoß.

@Rytmis:Elemente gelten nur dann als erledigt, wenn sie Testfälle haben.

Ohh, interessant.Ich sehe, dass ich das jetzt wirklich tun muss, sonst erledige ich nichts.Das macht Sinn.

@jmorris:Loswerden / Opfern.

Blendungen, Blendungen, Blendungen - Es besteht die Chance, dass ich lerne, und mit Unterstützung und Unterstützung kann ich ein sehr wichtiger und funktionaler Teil der Teams werden.Das ist jetzt eines meiner Handicaps, aber das wird nicht mehr lange so bleiben.Wenn ich es jedoch einfach nicht schaffe, verstehe ich, dass ich gehen werde.Ich denke, ich werde es bekommen.

Letzten Endes hat die Unterstützung meines Teams einen großen Anteil daran.Es ist immer willkommen, wenn sich jemand die Zeit nimmt, mir zu helfen und mir gute Gewohnheiten beizubringen.Danach wäre es großartig, über ein gutes Unterstützungsnetz zu verfügen.Es wäre immer wünschenswert, wenn jemand danach ein paar Mal vorbeikäme und den Code durchginge, um zu sehen, wie alles abläuft, nicht in einer Rezension an sich, sondern eher im Rahmen eines freundlichen Besuchs.

Argumentation, Vorbereitung, Unterricht, Nachbereitung, Unterstützung.

Mir ist aufgefallen, dass viele Programmierer den Wert des Testens auf einer rationalen Ebene sehen.Wenn Sie Dinge gehört haben wie „Ja, ich weiß, ich sollte das testen, aber ich muss das wirklich schnell erledigen“, dann wissen Sie, was ich meine.Auf emotionaler Ebene haben sie jedoch das Gefühl, dass sie nur dann etwas erreichen, wenn sie den echten Code schreiben.

Das Ziel sollte also darin bestehen, ihnen irgendwie klarzumachen, dass das Testen tatsächlich das ist nur Möglichkeit zu messen, wann etwas „erledigt“ ist, und ihnen so die intrinsische Motivation geben, Tests zu schreiben.

Ich fürchte allerdings, dass das viel schwieriger ist, als es sein sollte.Sie werden viele Ausreden hören wie „Ich habe es wirklich eilig, ich werde das später noch einmal umschreiben/umgestalten und dann die Tests hinzufügen“ – und natürlich findet die Nachverfolgung nie statt, weil sie überraschenderweise 'Re in der nächsten Woche genauso beschäftigt.

Folgendes würde ich tun:

Zum ersten Mal raus...„Wir werden dieses Projekt gemeinsam durchführen.Ich werde die Tests schreiben und Sie werden den Code schreiben.Achten Sie darauf, wie ich die Tests schreibe, denn so machen wir die Dinge hier und das ist es, was ich von Ihnen erwarte.
Im Anschluss daran..."Du bist fertig?Großartig!Schauen wir uns zunächst die Tests an, die Ihre Entwicklung vorantreiben.Oh, keine Tests?Lassen Sie mich wissen, wann das erledigt ist, und wir werden uns Ihren Code erneut ansehen.Wenn Sie Hilfe bei der Formulierung der Tests benötigen, lassen Sie es mich wissen und ich helfe Ihnen.“

Als junger Programmierer versuche ich immer noch, mich daran zu gewöhnen, Tests zu schreiben.Offensichtlich ist es nicht einfach, sich neue Gewohnheiten anzueignen, aber wenn ich darüber nachdenke, wie das für mich funktionieren könnte, muss ich den Kommentaren zu Codeüberprüfungen und Coaching/Pair-Programming +1 geben.

Es kann auch sinnvoll sein, den langfristigen Zweck des Testens hervorzuheben:Sicherstellen, dass das, was gestern funktioniert hat, heute, nächste Woche und nächsten Monat noch funktioniert.Ich sage das nur, weil ich beim Überfliegen der Antworten nicht gesehen habe, dass das erwähnt wurde.

Stellen Sie bei der Durchführung von Codeüberprüfungen (falls Sie sich dazu entschließen) sicher, dass Ihr junger Entwickler weiß, dass es nicht darum geht, ihn herabzusetzen, sondern darum den Code verbessern. Denn so ist es weniger wahrscheinlich, dass sein Selbstvertrauen beschädigt wird.Und das ist wichtig.Andererseits ist es auch wichtig, zu wissen, wie wenig man weiß.

Natürlich weiß ich nichts wirklich.Aber ich hoffe, dass die Worte nützlich waren.

Bearbeiten:[Justin Standard]

Machen Sie sich nicht schlecht, das, was Sie zu sagen haben, trifft im Großen und Ganzen zu.

Zu Ihrem Punkt zu Codeüberprüfungen:Sie werden feststellen, dass nicht nur der Nachwuchsentwickler dabei lernt, sondern auch die Prüfer.Jeder in einer Codeüberprüfung lernt, wenn Sie daraus einen kollaborativen Prozess machen.

Ehrlich gesagt, wenn Sie es sagen müssen Das Wenn Sie sich viel Mühe geben, ihn dazu zu bringen, etwas zu tun, müssen Sie sich möglicherweise mit dem Gedanken abfinden, dass er möglicherweise nicht gut in das Team passt und möglicherweise gehen muss.Nun, das bedeutet nicht unbedingt, dass er gefeuert wird ...Es kann bedeuten, dass er sich eine andere Stelle im Unternehmen sucht, zu der seine Fähigkeiten besser passen.Aber wenn es keinen anderen Ort gibt, wissen Sie, was zu tun ist.

Ich gehe davon aus, dass er ebenfalls ein relativ neuer Mitarbeiter ist (< 1 Jahr) und wahrscheinlich erst kürzlich die Schule verlassen hat. In diesem Fall ist er möglicherweise nicht daran gewöhnt, wie die Dinge in einem Unternehmensumfeld funktionieren.Mit solchen Dingen könnten die meisten von uns im College durchkommen.

Wenn dies der Fall ist, habe ich Werke gefunden, um eine Art "Überraschung neuer Miete" zu haben. Es spielt keine Rolle, ob Sie es noch nie zuvor getan haben ... er wird das nicht wissen.Setzen Sie ihn einfach hin und sagen Sie ihm, dass Sie seine Leistung durchgehen und ihm einige reale Zahlen zeigen werden. Nehmen Sie Ihr normales Bewertungsblatt (Sie haben doch einen formellen Bewertungsprozess, oder?) und ändern Sie die Überschrift, wenn Sie möchten, damit sie aussieht Beamter und zeigen Sie ihm, woran er ist.Wenn Sie ihm in einem sehr formellen Rahmen zeigen, dass sich das Nichtdurchführen von Tests negativ auf seine Leistungsbewertung auswirkt, anstatt ihn nur darüber zu „nörgeln“, wird er hoffentlich verstehen, worauf es ankommt.Sie müssen ihm zeigen, dass sich seine Handlungen tatsächlich auf ihn auswirken, sei es in Bezug auf die Bezahlung oder auf andere Weise.

Ich weiß, vielleicht möchten Sie davon Abstand nehmen, weil es nicht offiziell ist ...Aber ich denke, Sie sind im Rahmen der Vernunft, es zu tun, und es wird wahrscheinlich viel billiger sein, als ihn entlassen und jemanden neu einstellen zu müssen.

Er macht das bereits.Wirklich.Er schreibt es einfach nicht auf.Nicht überzeugt?Sehen Sie, wie er den Standardentwicklungszyklus durchläuft:

Schreiben Sie einen Code
Kompilieren Sie es
Führen Sie es aus, um zu sehen, was es bewirkt
Schreiben Sie den nächsten Code

Schritt #3 ist der Test.Er testet bereits, er macht es nur manuell.Stellen Sie ihm diese Frage:"Woher weißt du morgen, dass der Code von heute noch funktioniert?" Er wird antworten:„Es ist so wenig Code!“

Fragen:"Wie wäre es mit nächster Woche?"

Wenn er keine Antwort hat, fragen Sie:„Wie möchten Sie, dass Ihr Programm Ihnen mitteilt, wenn eine Änderung etwas kaputt macht, das gestern funktioniert hat?“

Darum geht es beim automatischen Unit-Testen.

Da ich selbst ein Junior-Programmierer bin, dachte ich, ich würde mal verraten, wie es war, als ich mich in einer ähnlichen Situation befand wie Ihr Junior-Entwickler.

Als ich die Uni zum ersten Mal verließ, stellte ich fest, dass ich dadurch nicht mehr in der Lage war, mich mit der realen Welt auseinanderzusetzen.Ja, ich kannte ein paar JAVA-Grundlagen und etwas Philosophie (fragen Sie nicht), aber das war es auch schon.Als ich meinen Job bekam, war es gelinde gesagt ein wenig entmutigend.Lassen Sie mich Ihnen sagen, dass ich wahrscheinlich einer der größten Cowboys überhaupt war. Ich habe einen kleinen Bugfix/Algorithmus ohne Kommentare/Tests/Dokumentation zusammengehackt und ihn rausgeschickt.

Ich hatte das Glück, unter einer Art Aufsicht zu stehen sehr geduldiger leitender Programmierer.Zu meinem Glück beschloss er, sich mit mir zusammenzusetzen und ein bis zwei Wochen damit zu verbringen, meinen sehr gehackten Code durchzugehen.Er würde mir erklären, wo ich einen Fehler gemacht hatte, die Feinheiten von c und Zeigern (Junge, das hat mich verwirrt!).Wir haben es geschafft, in etwa einer Woche einen ziemlich guten Kurs/Modul zu schreiben.Ich kann nur sagen, dass ich wahrscheinlich nicht lange durchgehalten hätte, wenn der leitende Entwickler nicht die Zeit investiert hätte, mir auf dem richtigen Weg zu helfen.

Glücklicherweise würde ich zwei Jahre später hoffen, dass einige meiner Kollegen mich vielleicht sogar für einen durchschnittlichen Programmierer halten würden.

Nehmen Sie Punkte mit nach Hause

Die meisten Universitäten sind sehr schlecht darin, Studierende auf die reale Welt vorzubereiten
Paired Programming hat mir wirklich geholfen.Das heißt nicht, dass es allen hilft, aber bei mir hat es funktioniert.

Weisen Sie sie Projekten zu, die keinen „stabilen Code höchster Qualität“ erfordern, wenn das Ihr Anliegen ist, und lassen Sie den Jr.Entwickler scheitern.Sorgen Sie dafür, dass sie diejenigen sind, die am Wochenende vorbeikommen, um ihre Fehler zu beheben.Essen Sie viel zu Mittag und sprechen Sie über Softwareentwicklungspraktiken (keine Vorträge, sondern Diskussionen).Mit der Zeit werden sie sich die Best Practices aneignen und entwickeln, um die ihnen zugewiesenen Aufgaben zu erledigen.

Wer weiß, vielleicht fällt ihnen sogar etwas Besseres ein als die Techniken, die Ihr Team derzeit verwendet.

Wenn der Junior-Programmierer oder irgendjemand sonst den Wert des Testens nicht erkennt, wird es schwierig sein, ihn dazu zu bewegen ... Punkt.

Ich hätte den Junior-Programmierer dazu gebracht, sein Wochenende zu opfern, um den Fehler zu beheben.Seine Handlungen (oder deren Unterlassung) wirken sich nicht direkt auf ihn aus.Machen Sie außerdem deutlich, dass er keine Beförderungen und/oder Gehaltserhöhungen erleben wird, wenn er seine Fähigkeiten beim Testen nicht verbessert.

Am Ende passt er trotz all Ihrer Hilfe, Ermutigung und Betreuung möglicherweise nicht in Ihr Team. Lassen Sie ihn also gehen und suchen Sie nach jemandem, der es versteht.

Ich schließe mich RodeoClowns Kommentar zur Codeüberprüfung bei jedem Commit an.Sobald er es ein paar Mal gemacht hat, gewöhnt er sich daran, Dinge zu testen.

Ich weiß jedoch nicht, ob Sie solche Commits blockieren müssen.An meinem Arbeitsplatz hat jeder ein kostenloses Commit für alles und alle SVN-Commit-Nachrichten (mit Diffs) werden per E-Mail an das Team gesendet.

Notiz:Du Wirklich will das Thunderbird-Addon für Farbunterschiede wenn Sie dies vorhaben.

Mein Chef oder ich (die beiden „leitenden“ Programmierer) werden am Ende die Commits durchlesen, und wenn es irgendwelche Dinge gibt wie „Sie haben vergessen, Unit-Tests hinzuzufügen“, schicken wir einfach eine E-Mail oder chatten mit der Person und erklären, warum sie das tun benötigte Unit-Tests oder was auch immer.Allen anderen wird empfohlen, auch die Commits zu lesen, da dies eine großartige Möglichkeit ist, zu sehen, was vor sich geht, aber die Junior-Entwickler kommentieren nicht so oft.

Sie können dazu beitragen, dass sich die Leute daran gewöhnen, indem Sie in regelmäßigen Abständen Dinge sagen wie: „Hey, Bob, hast du den Commit gesehen, den ich heute Morgen gemacht habe? Ich habe diesen netten Trick gefunden, mit dem du bla bla was auch immer machen kannst, den Commit liest und siehst.“ wie es funktioniert!"

Hinweis:Wir haben zwei „Senior“-Entwickler und drei Junior-Entwickler.Dies lässt sich möglicherweise nicht skalieren, oder Sie müssen den Prozess möglicherweise mit mehr Entwicklern etwas anpassen.

Beziehen Sie die Codeabdeckung in die Überprüfungen ein.
Machen Sie „einen Test schreiben, der den Fehler aufdeckt“ zur Voraussetzung für die Behebung eines Fehlers.
Erfordert einen bestimmten Abdeckungsgrad, bevor Code eingecheckt werden kann.
Finden Sie ein gutes Buch über testgetriebene Entwicklung und zeigen Sie anhand dessen, wie Test-First die Entwicklung beschleunigen kann.

Viel Psychologie und hilfreiche „Mentoring“-Techniken, aber ehrlich gesagt läuft es hier nur darauf hinaus: „Schreiben Sie Tests, wenn Sie morgen noch einen Job haben wollen.“

Sie können es so formulieren, wie Sie es für angemessen halten, hart oder sanft, das spielt keine Rolle.Tatsache ist jedoch, dass Programmierer nicht dafür bezahlt werden, nur Code zusammenzustellen und einzuchecken – sie werden dafür bezahlt, Code sorgfältig zusammenzustellen, dann Tests zusammenzustellen, dann ihren Code zu testen und DANN das Ganze einzuchecken.(Zumindest hört es sich Ihrer Beschreibung nach so an.)

Wenn sich also jemand weigert, seine Arbeit zu erledigen, erklären Sie ihm, dass er morgen zu Hause bleiben kann, und Sie werden jemanden einstellen, der die Arbeit erledigen WIRD.

Auch hier können Sie dies alles sanft tun, wenn Sie es für nötig halten, aber viele Leute brauchen einfach einen großen, harten Schlag Leben in der realen Welt, und Sie würden ihnen einen Gefallen tun, wenn Sie es ihnen geben würden.

Viel Glück.

Ändern Sie seine Stellenbeschreibung für eine Weile dahingehend, dass er sich ausschließlich auf das Schreiben und Warten von Tests konzentriert.Ich habe gehört, dass viele Unternehmen dies für neue, unerfahrene Leute für eine Weile tun, wenn sie anfangen.

Fordern Sie ihn außerdem heraus, während er diese Rolle innehat:Schreiben Sie Tests, die a) beim aktuellen Code fehlschlagen und a) die Anforderungen der Software erfüllen.Hoffentlich führt es dazu, dass er einige solide und gründliche Tests erstellt (und das Projekt verbessert) und dass er besser Tests schreiben kann, wenn er wieder in die Kernentwicklung einsteigt.

Bearbeiten> Erfüllt die Anforderungen der Software, was bedeutet, dass er nicht nur Tests schreibt, um den Code absichtlich zu beschädigen, wenn der Code diesen Testfall nie berücksichtigen sollte oder musste.

Wenn es Ihrem Kollegen an Erfahrung beim Schreiben von Tests mangelt, hat er oder sie möglicherweise Schwierigkeiten, über einfache Situationen hinaus zu testen, und das äußert sich in unzureichenden Tests.Folgendes würde ich versuchen:

Nehmen Sie sich etwas Zeit und teilen Sie Testtechniken wie Abhängigkeitsinjektion, Suche nach Randfällen usw. mit Ihrem Kollegen.
Bieten Sie an, Fragen zum Testen zu beantworten.
Führen Sie eine Zeit lang Codeüberprüfungen von Tests durch.Bitten Sie Ihren Kollegen, Ihre Änderungen zu überprüfen, die beispielhaft für gute Tests sind.Schauen Sie sich ihre Kommentare an, um zu sehen, ob sie Ihren Testcode wirklich lesen und verstehen.
Wenn es Bücher gibt, die besonders gut zur Testphilosophie Ihres Teams passen, geben Sie ihm oder ihr ein Exemplar.Es kann hilfreich sein, wenn Ihr Code-Review-Feedback oder Ihre Diskussionen auf das Buch verweisen, damit er oder sie einen Thread hat, den er oder sie aufgreifen und verfolgen kann.

Ich würde den Scham-/Schuldfaktor nicht besonders betonen.Es ist erwähnenswert, dass das Testen eine weit verbreitete und bewährte Methode ist und dass das Schreiben und Führen guter Tests eine professionelle Höflichkeit ist, sodass Ihre Teamkollegen ihre Wochenenden nicht bei der Arbeit verbringen müssen, aber ich möchte diese Punkte nicht weiter ausführen.

Wenn Sie wirklich „hart werden“ müssen, dann richten Sie ein unparteiisches System ein.Niemand mag das Gefühl, ausgegrenzt zu werden.Beispielsweise benötigt Ihr Team möglicherweise Code, um ein bestimmtes Maß an Testabdeckung aufrechtzuerhalten (der spielbar, aber zumindest automatisierbar ist);erfordern neuen Code, um Tests durchzuführen;Fordern Sie Prüfer auf, die Qualität von Tests zu berücksichtigen, wenn sie Codeüberprüfungen durchführen.und so weiter.Die Einführung dieses Systems sollte im Konsens des Teams erfolgen.Wenn Sie die Diskussion sorgfältig moderieren, entdecken Sie möglicherweise andere Gründe dafür, dass die Tests Ihres Kollegen nicht Ihren Erwartungen entsprechen.

Es liegt in der Verantwortung seines Mentors, ihn/sie zu unterrichten.Wie gut bringen Sie ihm/ihr bei, wie man Tests durchführt?Programmieren Sie paarweise mit ihm?Der Junior weiß höchstwahrscheinlich nicht, WIE man einen guten Test für xyz auf die Beine stellt.

Als frischgebackener Junior kennt er viele Konzepte.Etwas Technik.Etwas Erfahrung.Aber am Ende ist jeder Junior POTENZIAL.Bei fast jedem Feature, an dem sie arbeiten, wird es etwas Neues geben, das sie noch nie zuvor gemacht haben.Sicherlich hat der Junior vielleicht ein einfaches Zustandsmuster für ein Projekt im Unterricht erstellt und „Türen“ geöffnet und geschlossen, aber nie eine reale Anwendung der Muster.

Er/sie wird nur so gut sein, wie Sie gut unterrichten.Glauben Sie, dass sie, wenn sie es geschafft hätten, es einfach zu bekommen, überhaupt eine Junior-Position eingenommen hätten?

Meiner Erfahrung nach werden Junior-Mitarbeiter eingestellt und erhalten fast die gleiche Verantwortung wie Senior-Mitarbeiter, werden aber nur schlechter bezahlt und dann ignoriert, wenn sie ins Wanken geraten.Verzeihen Sie mir, wenn ich verbittert wirke, weil ich es bin.

@ jsmorris

Einmal hatte der leitende Entwickler und „Architekt“ mich und einen Tester (es war mein erster Job nach dem College) per E-Mail beschimpft, weil sie nicht lange geblieben waren und am Abend zuvor eine so „einfache“ Aufgabe erledigt hatten.Wir waren den ganzen Tag damit beschäftigt und hörten um 19 Uhr auf. Ich hatte an diesem Tag seit 11 Uhr vor dem Mittagessen geprügelt und jedes Mitglied unseres Teams mindestens zweimal um Hilfe gebeten.

Ich habe geantwortet und dem Team Folgendes hinzugefügt:„Seit einem Monat bin ich von dir enttäuscht.Ich bekomme nie Hilfe vom Team.Ich bin im Café auf der anderen Straßenseite, wenn du mich brauchst.Es tut mir leid, dass ich die Methode mit 12 Parametern und 800 Zeilen, von der fast alles abhängt, nicht debuggen konnte.“

Nachdem ich mich eine Stunde lang im Café abgekühlt hatte, ging ich zurück ins Büro, schnappte mir meinen Kram und ging.Nach ein paar Tagen riefen sie mich an und fragten, ob ich vorbeikommen würde. Ich sagte, ich würde es tun, aber ich hatte ein Vorstellungsgespräch, vielleicht morgen.

„Also hast du dann aufgehört?“

In Ihrem Quell-Repository:Verwenden Sie Hooks vor jedem Commit (z. B. Pre-Commit-Hook für SVN).

Überprüfen Sie in diesem Hook, ob für jede Methode mindestens ein Anwendungsfall vorhanden ist.Verwenden Sie eine Konvention für die Organisation von Unit-Tests, die Sie leicht über einen Pre-Commit-Hook durchsetzen können.

Kompilieren Sie alles auf einem Integrationsserver und überprüfen Sie regelmäßig die Testabdeckung mit einem Testabdeckungstool.Wenn die Testabdeckung für einen Code nicht 100 % beträgt, blockieren Sie jegliches Commit des Entwicklers.Er sollte Ihnen den Testfall zusenden, der 100 % des Codes abdeckt.

Nur automatische Prüfungen lassen sich gut auf ein Projekt skalieren.Man kann nicht alles von Hand überprüfen.

Der Entwickler sollte die Möglichkeit haben, zu überprüfen, ob seine Testfälle 100 % des Codes abdecken.Wenn er also keinen zu 100 % getesteten Code festschreibt, ist es seine eigene Schuld und kein „Ups, tut mir leid, ich habe es vergessen“-Fehler.

Erinnern :Menschen tun nie das, was Sie erwarten, sie tun immer das, was Sie inspizieren.

Zunächst einmal: Wie die meisten Befragten hier betonen, können Sie nicht viel dagegen tun, wenn der Mitarbeiter den Wert des Testens nicht erkennt, und Sie haben bereits darauf hingewiesen, dass Sie den Mitarbeiter nicht entlassen können.Allerdings ist Scheitern hier keine Option, also was ist mit den wenigen Dingen, die Sie tun? dürfen Tun?

Wenn Ihre Organisation groß genug ist, um mehr als 6 Entwickler zu beschäftigen, empfehle ich dringend, eine Qualitätssicherungsabteilung einzurichten (auch wenn es am Anfang nur eine Person ist).Idealerweise sollten Sie ein Verhältnis von 1 Tester zu 3-5 Entwicklern haben.Die Sache mit Programmierern ist ...Sie sind Programmierer, keine Tester.Ich habe noch nie einen Programmierer interviewt, dem offiziell die richtigen Qualitätssicherungstechniken beigebracht wurden.

Die meisten Unternehmen machen den schwerwiegenden Fehler, die Testrollen dem neuen Mitarbeiter zuzuweisen, der Person mit dem geringsten Kontakt zu Ihrem Code. Idealerweise sollten die leitenden Entwickler in die QA-Rolle versetzt werden, da sie über Erfahrung mit dem Code verfügen und haben (hoffentlich) einen sechsten Sinn für Codegerüche und Fehlerquellen entwickelt, die auftauchen können.

Darüber hinaus wird der Programmierer, der den Fehler gemacht hat, den Fehler wahrscheinlich nicht finden, da es sich normalerweise nicht um einen Syntaxfehler handelt (diese werden beim Kompilieren erkannt), sondern um einen Logikfehler – und die gleiche Logik ist am Werk, wenn er den Fehler schreibt testen, wie wenn sie den Code schreiben.Lassen Sie nicht die Person, die den Code entwickelt hat, diesen Code testen – sie wird weniger Fehler finden als jeder andere.

Wenn Sie sich in Ihrem Fall den umgeleiteten Arbeitsaufwand leisten können, machen Sie diesen neuen Mitarbeiter zum ersten Mitglied Ihres QA-Teams.Lassen Sie ihn „Softwaretests in der realen Welt“ lesen:„Improving The Process“, da er in seiner neuen Rolle offensichtlich eine gewisse Schulung benötigen wird.Wenn es ihm nicht gefällt, gibt er auf und Ihr Problem ist immer noch gelöst.

Ein etwas weniger rachsüchtiger Ansatz wäre, diese Person das tun zu lassen, worin sie gut ist (ich gehe davon aus, dass diese Person eingestellt wurde, weil sie im Programmierteil des Jobs tatsächlich kompetent ist) und einen oder zwei Tester mit der Durchführung der Tests zu beauftragen ( Universitätsstudenten haben oft ein Praktikum oder ein Praktikum absolviert, würden sich über die Möglichkeit freuen und sind günstig)

Randnotiz:Letztendlich möchten Sie, dass das QA-Team einem QA-Direktor unterstellt ist, oder zumindest nicht einem Softwareentwickler-Manager, da es einen Interessenkonflikt darstellt, wenn das QA-Team dem Manager Bericht erstattet, dessen Hauptziel darin besteht, das Produkt fertigzustellen.

Wenn Ihre Organisation weniger als 6 Personen umfasst oder Sie nicht mit der Bildung eines neuen Teams durchkommen, empfehle ich Paired Programming (PP).Ich bin kein völliger Befürworter aller extremen Programmiertechniken, aber ich bin definitiv ein Verfechter der Paarprogrammierung.Allerdings müssen beide Mitglieder des gepaarten Programmierteams engagiert sein, sonst funktioniert es einfach nicht.Sie müssen zwei Regeln befolgen:Der Prüfer muss vollständig verstehen, was auf dem Bildschirm codiert wird, oder er muss den Codierer bitten, es zu erklären.Der Programmierer kann nur das kodieren, was er erklären kann – „Sie werden es sehen“ oder „Vertrauen Sie mir“ oder Winken mit der Hand werden nicht toleriert.

Ich empfehle PP nur, wenn Ihr Team dazu in der Lage ist, denn wie beim Testen wird kein noch so großes Jubeln oder Drohen ein paar egoistische Introvertierte dazu bewegen, zusammenzuarbeiten, wenn sie sich dabei nicht wohl fühlen.Ich finde jedoch, dass zwischen der Wahl, detaillierte Funktionsspezifikationen zu schreiben und Codeüberprüfungen durchzuführen, vs.Beim gepaarten Programmieren setzt sich in der Regel das PP durch.

Wenn PP nichts für Sie ist, dann ist TDD die beste Wahl, aber nur, wenn es wörtlich genommen wird.Testgetriebene Entwicklung bedeutet, dass Sie die Tests ZUERST schreiben, die Tests ausführen, um zu beweisen, dass sie tatsächlich fehlschlagen, und dann den einfachsten Code schreiben, damit es funktioniert.Der Nachteil besteht darin, dass Sie jetzt über eine Sammlung von Tausenden von Tests verfügen (sollten), bei denen es sich ebenfalls um Code handelt und die genauso wahrscheinlich Fehler enthalten wie Produktionscode.Ich bin ehrlich gesagt kein großer Fan von TDD, vor allem aus diesem Grund, aber es funktioniert für viele Entwickler, die lieber Testskripte als Testfalldokumente schreiben – einige Tests sind besser als keine.Kombinieren Sie TDD mit PP, um die Wahrscheinlichkeit einer Testabdeckung zu erhöhen und weniger Fehler im Skript zu verursachen.

Wenn alles andere fehlschlägt, stellen Sie dem Programmierer das Äquivalent eines Schimpfglases zur Verfügung – jedes Mal, wenn der Programmierer den Build kaputt macht, muss er 20, 50, 100 US-Dollar (was auch immer für Ihre Mitarbeiter mäßig schmerzhaft ist) in ein Glas stecken, das an Ihren Favoriten geht ( registriert!) Wohltätigkeitsorganisation.Bis sie zahlen, meide sie :)

Spaß beiseite, der beste Weg, Ihren Programmierer dazu zu bringen, Tests zu schreiben, besteht darin, ihn nicht programmieren zu lassen.Wenn Sie einen Programmierer suchen, engagieren Sie einen Programmierer – Wenn Sie Tests wünschen, engagieren Sie einen Tester.Ich habe vor 12 Jahren als Junior-Programmierer mit dem Testen angefangen, und das hat sich zu meinem Karriereweg entwickelt, den ich gegen nichts eintauschen würde.Eine solide Qualitätssicherungsabteilung, die ordnungsgemäß gefördert wird und die Befugnis und den Auftrag erhält, die Software zu verbessern, ist genauso wertvoll wie die Entwickler, die die Software überhaupt schreiben.

Das mag etwas herzlos klingen, aber so wie Sie die Situation beschreiben, klingt es, als müssten Sie diesen Kerl feuern.Oder machen Sie es zumindest deutlich:Weigerung, Hausentwicklungspraktiken zu befolgen (einschließlich schriftlicher Tests) Und Wenn Sie fehlerhaften Code einchecken, den andere Leute bereinigen müssen, werden Sie irgendwann gefeuert.

Der Hauptgrund dafür, dass Nachwuchsingenieure/Programmierer sich nicht viel Zeit für das Entwerfen und Durchführen von Testskripten nehmen, liegt darin, dass die meisten CS-Zertifizierungen dies nicht unbedingt erfordern, sodass andere Bereiche des Ingenieurwesens in Hochschulprogrammen weiter abgedeckt werden, beispielsweise Designmuster.

Meiner Erfahrung nach besteht der beste Weg, Nachwuchskräfte daran zu gewöhnen, darin, dies explizit in den Prozess einzubeziehen.Das heißt, bei der Schätzung der Zeit, die eine Iteration dauern sollte, sollte die Zeit für das Entwerfen, Schreiben und/oder Ausführen der Fälle in diese Zeitschätzung einbezogen werden.

Schließlich sollte die Überprüfung des Testskriptdesigns Teil einer Designüberprüfung sein, und der eigentliche Code sollte im Rahmen der Codeüberprüfung überprüft werden.Dadurch ist der Programmierer dafür verantwortlich, jede von ihm geschriebene Codezeile ordnungsgemäß zu testen, und der leitende Ingenieur und seine Kollegen sind dafür verantwortlich, Feedback und Anleitung zum geschriebenen Code und Test zu geben.

Aufgrund Ihres Kommentars „Zeigen, dass das Design einfacher wird“ gehe ich davon aus, dass Sie TDD üben.Eine nachträgliche Codeüberprüfung wird nicht funktionieren.Das Ganze an TDD ist, dass es sich um ein Design und nicht um eine Testphilosophie handelt.Wenn er die Tests nicht als Teil des Entwurfs geschrieben hat, werden Sie keinen großen Nutzen daraus ziehen, Tests im Nachhinein zu schreiben – insbesondere für einen Nachwuchsentwickler.Am Ende werden ihm viele Eckfälle entgehen und sein Code wird immer noch beschissen sein.

Am besten haben Sie eine sehr geduldiger Senior-Entwickler, der mit ihm zusammensitzt und ein paar Paarprogrammierungen durchführt.Und bleiben Sie einfach dabei, bis er es lernt.Oder er lernt nicht. In diesem Fall müssen Sie ihm eine Aufgabe zuweisen, für die er besser geeignet ist, weil Sie dadurch nur Ihre echten Entwickler frustrieren.

Nicht jeder hat das gleiche Maß an Talent und/oder Motivation.Entwicklungsteams, auch agile, bestehen aus Leuten des „A-Teams“ und Leuten des „B-Teams“.Die Mitglieder des A-Teams sind diejenigen, die die Lösung entwerfen, den gesamten nicht-trivialen Produktionscode schreiben und mit den Geschäftsinhabern kommunizieren – all die Arbeit, die ein Denken über den Tellerrand hinaus erfordert.Das B-Team kümmert sich um Dinge wie Konfigurationsmanagement, das Schreiben von Skripten, das Beheben lahmer Fehler und die Durchführung von Wartungsarbeiten – all die Arbeiten, die strengen Verfahren unterliegen und bei Fehlern nur geringe Konsequenzen haben.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow