Wie motiviere ich Mitarbeiter, Unit-Tests zu schreiben? [geschlossen]

Wir arbeiten an einem großen Produkt, das seit ca. 5 Jahren in Produktion ist. Die Codebasis funktioniert .. ähm ... Nicht wirklich gut, aber es funktioniert. Neue Funktionen werden in die Produktion übernommen und mit einer kleinen Qualitätssicherung getestet. Bugs sind behoben, etc. Aber niemand außer mir schreibt Unit-Tests. Niemand nutzt die Fähigkeit, Fehler durch Schreiben von Komponententests "aufzuspüren", um sicherzustellen, dass dieser spezielle Fehler (Testfall) nie wieder auftreten wird.

Ich habe mit dem Management gesprochen. Ich habe mit Entwicklern gesprochen. Ich habe mit allen in der ganzen Firma gesprochen. Alle sagen: "Ja, wir müssen mehr Unit-Tests schreiben!" Das war vor ungefähr einem Jahr. Seitdem habe ich die Einführung von Pre-Commit Code Review ( Gerrit ) und Continuous Integration ( Jenkins ) erzwungen .

Ich habe einige Treffen über Unit-Tests abgehalten und auch die Vorteile des Schreibens von Unit-Tests aufgezeigt. Aber niemand scheint interessiert zu sein.

F1: Wie motiviere ich meine Kollegen, Unit-Tests zu schreiben?

F2: Wie bleibe ich motiviert, meinen persönlichen Code-Qualitätsstandards zu folgen? (Manchmal ist es wirklich frustrierend!)

PS: Einige frustrierende Fakten (in 1 Jahr erreicht):

• Gesamtzahl der Tests: 1693
• Insgesamt "Beispiel-Unit-Tests": rund 50
• Geschehen von mir: 1521

Edit: Erwarte ich zu viel? Es ist mein erster Arbeitsplatz und ich versuche mein Bestes zu geben.

Edit 2: Basierend auf allen Antworten habe ich eine kleine Checkliste für mich erstellt. Ich habe privat mit zwei Entwicklern gesprochen und wir hatten ein gutes und ehrliches Gespräch.

Einer von ihnen sagte mir, wie Telastyn sagte, dass er mit Unit-Tests wirklich unwohl ist. Er sagte, dass er "professioneller" sein möchte, aber er braucht einen Kickstart. Er sagte auch, dass unser Unit-Test-Meeting mit allen Entwicklern (gegen 9-11) gut war, aber es war zu voll. Meh. Einige Kritiker für mich, aber ich werde daraus lernen. (Siehe Antworten unten bezüglich Tdd Kata Meetings!)

Der andere sagte, er habe kein Interesse daran, Unit-Tests zu schreiben. Er denkt, dass seine Arbeit gut genug für sein Gehalt ist. Er will sich nicht mehr anstrengen. Ich war ziemlich sprachlos. Typische 9-5 "Arbeiter".

Nächste Woche werde ich mit den anderen Entwicklern sprechen.

Vielen Dank für Ihre großartigen Antworten (soweit!) Und Ihre Unterstützung. Ich weiß das wirklich zu schätzen! Ich habe viel gelernt, vielen Dank!

Mir ist aufgefallen, dass es kaum funktioniert, über TDD zu sprechen. Die Leute sehen gerne rohe Ergebnisse . Zu behaupten, dass "das Schreiben von Tests die Entwicklungszeit verkürzt", ist höchstwahrscheinlich richtig, reicht jedoch möglicherweise nicht aus, um jemanden davon zu überzeugen.

Ich war in einer ähnlichen Position (naja, nicht so schlecht wie deine) und es löste sich von selbst auf, als die Leute anfingen, an meinem Code zu arbeiten (Anmerkung: Mein Code wurde anhand von Einheiten getestet, andere weniger). Wenn etwas nicht mehr funktionierte, sollte ich nach einer Untersuchung vor Ort natürlich gefragt werden, was der Grund sein könnte . Dann setzten wir uns, führten Unit-Tests durch und sahen, was passierte. Wenn Tests bestanden wurden, lagen die meisten Probleme im neuen, nicht getesteten Code. Wenn nicht, konnten Tests normalerweise das Problem erkennen (oder uns zumindest in die richtige Richtung lenken). Wir haben den Fehler behoben, die Tests waren wieder in vollem Gange, alle waren glücklich.

Lange Rede, kurzer Sinn, ein paar Situationen wie diese tauchten auf und zwei weitere Entwickler wurden zu TDD- / Test-Enthusiasten (es sind noch ein paar übrig, aber es sieht vielversprechend aus).

Als Ratschlag können Sie TDD kata ausprobieren. einfache Aufgabe, die mithilfe eines Test-First-Ansatzes anstatt ohne Tests implementiert werden kann . Je nachdem, wie komplex die Aufgabe ist, sollte der Ansatz ohne Test normalerweise langsamer sein, insbesondere bei inkrementellen erforderlichen Änderungen:

• Roys Saitenrechner
• Bank OCR

Bearbeiten : OP Kommentar wurde mir klar , es gibt noch stärkeres Argument zu seiner Verfügung - Regression aka Rückkehr Bugs . Solche Situationen sind perfekte Beispiele dafür, wie nützlich Unit-Tests sein können. Menschen, die Zahlen mögen - wie ich bereits sagte: "Einheitentests sind gut", sind vielleicht nicht überzeugend, aber das Anordnen von Daten wie den folgenden könnte sicherlich Folgendes sein:

• Zeitaufwand für die Implementierung der Funktion (es wurden keine Tests geschrieben; ich gehe davon aus, dass dies häufig vorkam, daher sollte es relativ einfach sein, ein solches Beispiel zu finden.)
• Geschätzte Zeit für die Implementierung der Funktion mit TDD (oder sogar für Tests nach dem Anflug; spielt keine Rolle - wichtig ist das Vorhandensein von Komponententests)
• Zeitaufwand für die Behebung des Fehlers bei ungetestetem und getestetem Code

Eine Sache, vor der Sie gewarnt werden sollten (dies ist offensichtlich, aber bemerkenswert): Ergebnisverzerrung - stellen Sie sicher, dass Sie kein Beispiel auswählen, bei dem die einzige Möglichkeit zum Erkennen eines Fehlers mit einem Test darin bestand, einen Test für diesen Fehler zu schreiben. Normalerweise weiß niemand, dass ein Fehler im Voraus auftreten wird, aber es ist verlockend zu sagen, "Mann, dieser Fehler wäre trivial, wenn wir einen Test für X hätten" - es ist einfach, eine Siegertaktik für einen Krieg nach dessen Ende zu finden.

Das Ergebnis dieser Beispiele sollte eine einfache Frage sein - wenn Sie x-Stunden damit verbringen könnten , Feature Y zu entwickeln, warum sollten Sie darauf bestehen, es in 2x zu tun ?

Zuerst muss man wissen, warum sie keine Tests schreiben.

Enge Entwicklungspläne sind oft der Grund, aber Sie sagen, dass Sie das nicht haben.

Der nächste Grund ist, dass das Schreiben von Tests bei einer großen, noch nicht getesteten Codebasis wahrscheinlich überwältigend erscheint - ein Job, der nie zu Ende geht (wie Wäsche und ungefähr genauso aufregend). Die menschliche Natur ist also der Meinung, dass das zu viel ist, als dass man sich damit auseinandersetzen könnte, also werde ich es überspringen.

Ein weiterer Grund könnte sein, dass sie Tests für eine gute Idee halten, aber nicht sicher sind, wie sie anfangen sollen, sie zu schreiben, insbesondere wenn sie noch nie an einem Ort gearbeitet haben, an dem sie geschrieben wurden.

Eine andere starke Möglichkeit ist, dass sie wirklich keinen Wert für mehr Arbeit sehen, obwohl sie der Idee ein Lippenbekenntnis geben.

Wie gehen Sie mit den verschiedenen Gründen um?

Grund eins ist einfach, zeigen Sie ihnen ein Beispiel, wie es Entwicklungszeit spart.

Grund zwei: Zeigen Sie ihnen, wie viele Tests Sie in einem Jahr geschrieben haben und wie viel Prozent der Codebasis davon abgedeckt sind. Rechnen Sie nach, wie viele weitere Tests sie nächstes Jahr um diese Zeit durchführen könnten, wenn sie dies tun. Sobald sie sehen, dass sich kleine Fortschritte auf täglicher Basis wirklich summieren, ist die ganze Idee nicht mehr so ​​überwältigend. Wenn Sie die Daten aus dem System ziehen können, zeigen Sie ihnen, wie viele Fehler Wiederholungsfehler in den ungetesteten Teilen des Codes waren und wie viele Wiederholungsfehler im Code bei Komponententests auftreten.

Grund 3 ist Training, nicht nur Zeigen. Lassen Sie sie in einer Schulungsklasse Tests schreiben.

Grund 4, das ist der springende Punkt. Wählen Sie zunächst einen Schmerzpunkt aus, einen dieser Fehler, die mehrfach zurückgekehrt sind. Wenn dies eintrifft, ist dies die Zeit, dem Management vorzuschlagen, dass es nicht wie ein schlechter Pfennig zurückkommen würde, wenn es Einheitentests für diesen Gegenstand gäbe.

Eine andere Möglichkeit, Grund 4 zu beheben, besteht darin, dass das Management es zum Teil des Prozesses macht und der Code die Codeüberprüfung nur dann besteht, wenn die Tests auch die Codeüberprüfung bestehen. Am besten wenden Sie sich an sie, indem Sie dies zu einer Richtlinie machen, gleich nach einem dieser Probleme oder vorzugsweise gleich, nachdem Sie innerhalb weniger Tage mehrere hatten.

Wir alle denken gerne, dass wir uns als Entwickler selbst verwalten (LOL), aber der Ehrgeizige wird sich darum kümmern, was das Management für ihn bedeutet, und die Profis, die sich wirklich selbst verwalten, schreiben bereits die Tests. Wenn es den Mitarbeitern nicht darum geht, professionell zu sein und Best Practices umzusetzen, weil sie das Produkt verbessern, oder wenn es ihnen darum geht, Manager davon zu überzeugen, befördert zu werden (oder nicht entlassen zu werden), sollten Sie überlegen, ob dies der richtige Ort für Sie ist. Wenn Sie das Management nicht dazu bringen können, sich um Best Practices zu kümmern, werden Sie den ganzen Weg bergauf kämpfen, und Sie werden möglicherweise einschätzen, ob dies die richtige Unternehmenskultur für Sie ist. Während jeder Arbeitsplatz seine Probleme hat (und weglaufen nicht immer die Antwort ist), scheint dieser Ort nicht zu Ihrer Professionalität zu passen.

Ich würde damit beginnen , die Vorteile von TDD zu demonstrieren. Versuchen Sie, die Vorteile von Komponententests herauszustellen.

Entwickler sind wie normale Menschen von Vorteilen motiviert. Sie wollen keine Dinge tun, die nur mehr Arbeit schaffen. Unit Testing bedeutet weniger Arbeit . Es bedeutet, mehr mit Freunden auszugehen. Das bedeutet mehr Spaß, da Sie nicht jede Nacht bis 23:00 Uhr mit dem Programmieren verbringen müssen. Es bedeutet, mehr in den Urlaub zu fahren, ohne sich Gedanken zu machen.

Einer der größten Vorteile von TDD ist, dass Sie Ihr Programm zu einem besseren Design umgestalten oder einfach den Namen von etwas ändern können. Solange dieses Design die Tests nicht durchbricht, können Sie zu 100% sicher sein, dass sich Ihre Änderungen ändern habe nichts kaputt gemacht.

Ein weiterer großartiger Fall für TDD ist das Erstellen von Komponententests für älteren Code . Dies wäre eine der besten Möglichkeiten, um das Böse umzugestalten. Auf lange Sicht wird dies dazu dienen, Ihr Wissen über die Codebasis zu verbessern, ihre Stärken und Mängel zu verstehen, hartcodierte Geschäftslogik im Code zu erkennen und Ihnen einen guten Anfang zu geben, um die Qualität in Zukunft zu verbessern!

Gute Referenzen für die weitere Lektüre:

• Warum sollten Sie Unit-Tests schreiben
• Motivation Sichtbarkeit und Unit Testing
• Die Kunst des Komponententests, so Roy Osherove

http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first

Ich glaube, ich habe diesen Link vor einiger Zeit aus einem Artikel von Jeff Atwood mit einem Lesezeichen versehen [edit: yep, here it is] . Alt aber relevant. Aufgrund dieser und anderer Vorteile, die zweifellos in anderen Antworten beschrieben werden, sollten Ihre Programmierer in der Lage sein, sich selbst zu motivieren ! Dadurch können sie effizienter arbeiten und ihre Arbeit ein wenig erleichtern. Wer will das nicht?

In Bezug auf Ihre zweite Frage: Ihr Verantwortungsbewusstsein und Ihr Stolz auf Ihre Code-Qualitätsstandards sollten Sie dabei unterstützen . Überlegen Sie, was Sie mit solchen Standards erreichen möchten und wer davon profitiert. Meine persönlichen Codestandards können ebenfalls frustrierend sein, aber ich habe immer das Gefühl, dass ich der Welt / Firma / dem Team einen Gefallen tue, indem ich sie implementiere. Ich glaube nicht, dass Sie versuchen, zu viel zu tun - die Ergebnisse variieren von Ort zu Ort, aber zumindest bemühen Sie sich.

Dies scheint ein großer Vorbild zu sein .

Es gibt zwei inhärente Aspekte der menschlichen Natur, gegen die Sie kämpfen:

• Kreative mögen keine Prozesse.
• Die meisten Menschen mögen keine externen negativen Urteile über ihre Qualität.

Es ist sehr schwer, dies mit Vorträgen, Managementerklärungen oder sogar Logik zu bekämpfen. Sie müssen gewinnen, indem Sie einen alternativen Aspekt der menschlichen Natur ausnutzen.

• Die Menschen ahmen das Verhalten der besten Mitarbeiter nach

Wenn die besten Mitarbeiter TDD verwenden und es funktioniert, wird der Prozess erweitert. Wenn nicht, wird es nicht. Wenn Sie jemanden überzeugen müssen, sind es die besten 1 oder 2 Mitarbeiter.

Frag sie.

Sie sagen, dass den Leuten gesagt wurde, dass sie mehr Tests schreiben sollten. Warum sind sie nicht?

Es kann nicht (oft nicht) eine Frage der einfachen Motivation sein. Sie könnten sie vergessen. Sie könnten sich unter Zeitdruck fühlen. Sie wissen vielleicht nicht, wie man gute Tests schreibt. Sie denken vielleicht, dass Sie so gut sind, dass sie es nicht tun müssen. Wenn Sie die Ursache kennen, können Sie das Problem besser lösen.

Sie würden denken, die Unit-Tests wären der Verkauf an sich. Ich weiß nicht, wie Ihr Unternehmen funktioniert, aber wenn während eines Produktions-Rollouts ein Problem auftritt, arbeiten wir daran, bis es behoben ist. Es ist egal, ob es an einem Sonntagmorgen um 2 Uhr morgens passiert. Dies ist sehr selten für uns, aber wenn es das tut, ist es scheiße.

Ich begann damit, sie zu fragen, wie oft sie mitten in der Nacht aufstehen mussten, um ein größeres Problem zu beheben, das bei automatisierten Tests leicht gefunden werden konnte. Das heißt nicht, dass automatisierte Tests alles reparieren, aber es sollte helfen, das zu reduzieren.

Der zweite Verkaufsschlager ist der QS-Zyklus. Vor dem Start von TDD in meinem Unternehmen haben wir wöchentlich neue Releases an QA weitergegeben, um sie zu testen. Sie würden einen Haufen Bugs aus dieser Version erstellen, wir beheben diese Bugs und veröffentlichen eine neue Version. Wiederholen, bis fertig. Das erste Projekt, an dem wir TDD durchgeführt haben, erforderte erst einige Wochen später einen Push-out zur Qualitätssicherung. Und die Anzahl der gefundenen Bugs war sehr, sehr gering. 10% im Vergleich zu einem ähnlichen Projekt. Müssen Sie diese Statistiken trotzdem für Ihr Team zusammenstellen?

Das andere große Verkaufsargument war, wie der Code aussah, nachdem TDD angenommen wurde. Er war leichter zu lesen, weil wir ihn einfacher testen wollten. Zeigen Sie einen Vergleich zwischen Code, der für Komponententests geschrieben wurde, und nicht geschriebenem Code an.

Zeigen Sie ihnen schließlich, wie sie Code sicher umgestalten können.

Denken Sie daran, wenn Sie keine Tests schreiben möchten. :)

Ich möchte auf die Antwort von HLGEM eingehen , insbesondere auf diesen Abschnitt:

Der nächste Grund ist, dass das Schreiben von Tests bei einer großen, noch nicht getesteten Codebasis wahrscheinlich überwältigend erscheint - ein Job, der nie zu Ende geht (wie Wäsche und ungefähr genauso aufregend). Die menschliche Natur ist also der Meinung, dass das zu viel ist, als dass man sich damit auseinandersetzen könnte, also werde ich es überspringen.

Ich habe festgestellt, dass Code, den ich mit der Absicht schreibe, Tests zu schreiben, bedeutend besser ist als Code, den ich ohne die Absicht schreibe, Tests zu schreiben. frage mich Wie teste ich diese Funktion? Erzwingt eine bessere Gestaltung jeder einzelnen Funktion. (Weniger Abhängigkeit von globalen oder semi-globalen Daten; E / A von der Berechnung getrennt; Funktionen machen nur eine Sache; konsistente Fehlerbehandlung und so weiter.)

Der Versuch, alten Code zu testen, der nicht mit Blick auf das Testen geschrieben wurde, ist möglicherweise mehr als frustrierend.

Ich habe ein paar Techniken angewendet:

a) Richten Sie einen automatisierten Build ein. Wenn jemand etwas kaputt macht, das Sie getestet haben, zeigen Sie ihm, wie der Test es erkannt hat und wie schlimm der Fehler gewesen wäre.

b) Führen Sie komplexe Projekte mit Tests durch (Sie fahren). Dies wird zeigen, wie wenige Fehler in diesem Projekt existieren. Ich hatte ein komplexes Server-Interaktionsprojekt, das einwandfrei funktioniert hat. Die Qualitätssicherung ist nie fehlgeschlagen und alle Integrationstests verliefen zu 100% reibungslos. Dieses System wurde als sehr stabil bekannt und das gesamte Management war damit zufrieden. Was Sie in diesen Situationen tun, ist vorhanden, wie Unit-Tests dies ermöglichten.

c) Ziehen Sie jeweils eine Person ein. Derjenige, der auf dich hört. Stelle dich Fehlern und zeige, wie Tests tiefe und schwierige Probleme aufdecken. Das hilft. Es ist nie einfach. Aber sobald Sie einen Fan bekommen, wird er nur helfen. Es ist ein Dominoeffekt.

Backeinheitentest im Prozess. Wenn ein Fehler in der Produktion auftaucht, der zu offensichtlich ist, um ihn im Unit-Test zu fangen, übernimmt dieser Typ die Schuld. Weisen Sie die Leute an, jeden Test zu schreiben, den sie machen. Wählen Sie nach dem Zufallsprinzip Fälle aus und beobachten Sie wöchentlich die Ausführung weniger Fälle. Durch Unit-Tests fragen die Leute nach den Anforderungen und binden sie schließlich an die Entwicklung und entwickeln hoffentlich Software, die sowohl benötigt wird als auch funktioniert :)