Ich möchte meinen Mitarbeitern das Konzept der Komponententests (und Tests im Allgemeinen) vorstellen. Im Moment gibt es überhaupt keine Tests und die Dinge werden getestet, indem die Aufgaben über die Benutzeroberfläche ausgeführt werden, um das gewünschte Ergebnis zu sehen. Wie Sie sich vielleicht vorstellen können, ist der Code sehr eng an die genaue Implementierung gekoppelt. Dies kann sogar dazu führen, dass Code, der in einer Klasse enthalten ist und systemweit wiederverwendet wird, methodenübergreifend kopiert und eingefügt wird.

Aufgrund geänderter Anforderungen wurde ich gebeten, ein Modul zu ändern, das ich zuvor geschrieben habe, und das ziemlich locker gekoppelt ist (nicht so viel, wie ich möchte, aber so gut ich kann, ohne viele andere Konzepte einführen zu müssen). Ich habe beschlossen, meinem überarbeiteten Code eine Reihe von Komponententests beizufügen, um zu "beweisen", dass er wie erwartet funktioniert, und um zu demonstrieren, wie das Testen funktioniert. Ich verfolge kein echtes TDD, da ein Teil des Codes bereits geschrieben ist, aber ich hoffe, dass ich einige TDD-Konzepte für den neuen Code befolgen kann, den ich erstellen muss.

Jetzt bin ich mir sicher, dass ich gefragt werde, warum ich mehr als ein oder zwei Tage brauche, um den Code zu schreiben, da Teile von dem, mit dem ich interagieren werde, bereits im System vorhanden sind (wenn auch ohne Tests und sehr eng gekoppelt), und wenn ich den Code einchecke, werde ich gefragt, was dieses "Tests" -Projekt ist. Ich kann die Grundlagen des Testens erklären, aber ich kann die tatsächlichen Vorteile nicht so erklären, wie es die anderen verstehen würden (weil sie glauben, dass Sie die App zum Testen selbst ausführen müssen, da häufig die tatsächliche Benutzeroberfläche für die Bestimmung der Funktionsfähigkeit der Funktion von Bedeutung ist " oder nicht). Sie verstehen die Idee der losen Kopplung nicht (deutlich erkennbar an der Tatsache, dass nichts lose gekoppelt ist; es gibt nicht einmal Schnittstellen außerhalb des von mir geschriebenen Codes). Der Versuch, das als Vorteil zu nutzen, würde mir wahrscheinlich ein "Huh?" Ich kann nicht so locker sein, wie ich es gerne hätte, ohne mehrere vorhandene Module überarbeiten zu müssen und wahrscheinlich eine Art IoC-Container einzuführen, was als Zeitverschwendung und nicht als "Programmieren" angesehen würde.

Hat jemand Vorschläge, wie ich auf diesen Code verweisen und "Wir sollten mit der Erstellung von Komponententests beginnen" sagen kann, ohne dass dies als herablassend eingestuft wird (z. B. "Wenn Sie Tests schreiben, müssen Sie guten Code schreiben")? außer meins ist schlecht ) oder ohne es wie eine Zeitverschwendung erscheinen zu lassen, die keinen wirklichen Wert hinzufügt?

Ich möchte meinen Mitarbeitern das Konzept der Komponententests (und Tests im Allgemeinen) vorstellen

Ich denke, es ist vielleicht besser, von der praktischen Seite auszugehen, nicht von der konzeptionellen. Wenn Sie in lockeren Gesprächen feststellen, dass Ihre Mitarbeiter und / oder die Geschäftsleitung an Unit-Tests interessiert sind, sollten Sie einige konkrete Erfahrungen / Beweise aus dem Internet recherchieren, eine kurze Schulung zusammenstellen usw. Wie Sie beschreiben, scheinen Ihre Teamkollegen dieser seltsamen neuen Idee jedoch nicht sehr aufgeschlossen zu sein.

In einer solchen Situation würde ich einfach anfangen, meine kleinen Unit-Tests zu schreiben, ohne zu versuchen, es zuerst jemandem zu erklären. Fügen Sie einige davon hinzu, wenn ich den Code ändere, ohne zu versuchen, den gesamten Code gründlich abzudecken (was übermäßig viel Zeit in Anspruch nehmen würde). Wenn es mir gelingt, ein gutes Gleichgewicht zu finden, kann es sein, dass ich, wenn sie bemerken, dass ich Unit-Tests schreibe, bereits eine umfangreiche Testsuite habe und einige konkrete Ergebnisse vorweisen kann (wie "mit diesem Testfall habe ich es geschafft, einen Fehler zu finden eingeführt durch die Änderung der letzten Woche, die sonst zur Qualitätssicherung / Produktion durchgerutscht wäre "). Das wird jedem ernsthaften Entwickler den Wert der Tests beweisen.

Danach bin ich in der Lage, die langfristigen Vorteile von Unit-Tests zu erläutern, wie z

• es beweist, dass der Code funktioniert - jederzeit, überall, sofort und automatisch, was wiederum der Fall ist
• gibt dem Refactor Vertrauen, was zu einem verbesserten Design und einer besseren Wartbarkeit führt,
• Und wenn etwas kaputt geht, erhalten Sie durch Unit-Tests (fast) sofortiges Feedback, im Gegensatz zu einer Verzögerung von mehreren Tagen oder Wochen, wenn der Fehler von einer separaten QA-Abteilung abgefangen wird. So können Sie den Fehler in der Regel in Sekundenschnelle beheben, anstatt stunden- / tagelang in Code zu debuggen, der seit langem aus Ihrem Kurzzeitgedächtnis entfernt wurde.

Siehe auch diesen verwandten Thread: Automatisiertes Unit-Testen, Integrationstesten oder Abnahmetesten .

Und eine frühere von SO: Was ist Unit Testing?

Refaktor ohne Angst

Mit TDD können Sie "ohne Angst neu faktorisieren". Dies ist ein entscheidender Vorteil, den Sie Ihrem Team bieten können. Es hindert Entwickler daran, sich selbst zu sagen:

• "Ich möchte diesen Code nicht anfassen, weil ich Angst habe, ihn zu knacken."
• "Ich möchte keine neuen Funktionen für diesen Code schreiben, weil ich nicht weiß, wie es funktioniert."
• "Insgeheim habe ich Angst vor diesem Code"

Ich könnte auf mehr Harfe spielen, aber dies ist ein gut durchdachter Bereich, wie Onkel Bob bei TDD und Martin Fowler bei TDD .

Abhängigkeiten

Oh, ich werde noch eine Sache hinzufügen. Es wird ihnen gezeigt, wie TDD gutes Design erzwingt, wodurch Sie Abhängigkeiten sauber verarbeiten können.

Bob: "Oh c% ^ p! Die Chefs haben uns alle gezwungen, MS SQL Server 2008 zu verwenden." Jane: "Das ist in Ordnung. Der Schaden wurde minimiert, da wir unsere Datenquelle und unsere DAO-Klassen DIENEN. Ich bin so froh, dass TDD uns ermutigt hat uns auf diesem Weg. "

Während wir an Quellcode arbeiten, der keine automatisierten Tests hat, müssen wir sehr sorgfältig arbeiten und benötigen mehr Überprüfungen, um zuversichtlich zu bleiben, dass die von uns vorgenommenen Änderungen keine der vorhandenen Funktionen beeinträchtigen.

Wenn wir gute automatisierte Testfälle haben, werden die Konsequenzen eine schnellere, sicherere und furchtlosere Entwicklung sein (es kann sich um Fehlerbehebung, Verbesserung oder Re-Factoring handeln).

Rechne nach

• t _mt = die Zeit, die benötigt wird, um alles manuell zu testen, was Sie möglicherweise beeinflussen
• t _wt = die Zeit, die zum Schreiben der Tests benötigt wird

• k = die Häufigkeit, mit der Sie wahrscheinlich alles testen müssen, bevor Sie den neuen Code veröffentlichen

  Wenn (t _wt <t _mt ) oder (t _wt <(k * t _mt )), ist es ein Kinderspiel: Das Schreiben der Tests beschleunigt die Entwicklung.

ansonsten schaue auf das Verhältnis (t _wt / (k * t _mt )). Wenn es sich um eine sehr große Zahl handelt, warten Sie auf eine andere Gelegenheit. Ansonsten rechtfertigen Sie mit Regressionstests Vorteile.

Hinweis: Ich schlage an dieser Stelle vor, nur Features zu testen, keine Einheiten - viel einfacher zu rechtfertigen und zu verstehen, und vermutlich weniger mit höherem Wert zu arbeiten als bloße Einheitentests beim Refactoring.

Hinweis 2: Die Zeit, die zum Ausführen der Tests benötigt wird, spielt keine Rolle , da sie automatisiert sind. Sie können während der Ausführung der Tests etwas anderes Produktives tun, es sei denn, die Tests dauern so lange, dass Sie die Frist verpassen. Welches ist selten.

Ein Vorschlag , wenn Sie ein Microsoft - Shop: eine Dokumentation auf MSDN finden , die Unit - Tests oder lose couping als Best Practice empfiehlt (ich bin sicher , es gibt mehrere Instanzen dieses ) und zeigen auf, ob es Konflikte gibt.

Es mag sich nach einer krassen Vorgehensweise anhören, aber ich habe festgestellt, dass die Verwendung des Begriffs „Best Practice“ Sie vor allem beim Management weit bringen wird.

Wie ich immer empfehle, besteht der beste Weg, um eine großartige Praxis sanft in Ihre Umgebung einzuführen, darin, sie selbst zu machen, und dann werden einige Ihrer Mitarbeiter den Nutzen und die Vorteile erkennen Heb es auf.

Das Schlüsselwort lautet hier Evolution, nicht Revolution.