Methodik: Komponententests für einen anderen Entwickler schreiben

Ich dachte über Softwareentwicklung nach und schrieb Unit-Tests. Ich habe folgende Idee:

Nehmen wir an, wir haben Entwicklerpaare. Jedes Paar ist für einen Teil des Codes verantwortlich. Einer aus dem Paar implementiert eine Funktion (Schreiben von Code) und der zweite schreibt einen Komponententest dafür. Tests werden nach Code geschrieben. In meiner Vorstellung helfen sie sich gegenseitig, arbeiten aber eher getrennt. Im Idealfall würden sie an zwei Features ähnlicher Größe arbeiten und diese dann zur Testvorbereitung austauschen.

Ich denke, dass diese Idee einige Vorteile hat:

• Tests werden von jemandem geschrieben, der mehr über die Implementierung sehen kann,
• Die Arbeit sollte etwas schneller als die Paarprogrammierung erfolgen (zwei Funktionen gleichzeitig).
• Beide Tests und der Code haben die verantwortliche Person dafür.
• Code wird von mindestens zwei Personen getestet
• Vielleicht würde die Suche nach Fehlern in Code, der von einer Person geschrieben wurde, die Ihren Code testet, eine besondere Motivation für das Schreiben von besserem Code und das Vermeiden von Schnitten geben.

Vielleicht ist es auch eine gute Idee, einen anderen Entwickler für die Codeüberprüfung zwischen Code- und Testentwicklung hinzuzufügen.

Was sind die Nachteile dieser Idee? Wird es bereits als unbekannte Methode beschrieben und in der Softwareentwicklung verwendet?

PS. Ich bin kein professioneller Projektmanager, aber ich kenne mich mit Projektentwicklungsprozessen aus und kenne die wenigen gängigen Methoden - aber diese Idee kommt mir nicht bekannt vor.

Der allgemeine Ansatz, Paare zu verwenden, um den Aufwand für das Schreiben von Produktionscode und die damit verbundenen Komponententests aufzuteilen, ist nicht ungewöhnlich. Ich habe mich auf diese Weise schon einmal persönlich mit anständigem Erfolg gepaart. Eine strenge Linie zwischen der Person, die den Produktionscode schreibt, und der Person, die den Testcode schreibt, muss jedoch nicht unbedingt zu Ergebnissen führen.

Wenn ich einen ähnlichen Ansatz gewählt habe, fängt das Paar damit an, zu sprechen und sich ein gemeinsames Verständnis des Problems zu verschaffen. Wenn Sie TDD verwenden, können Sie zunächst mit einigen grundlegenden Tests beginnen. Wenn Sie TDD nicht verwenden, beginnen Sie möglicherweise mit der Methodendefinition. Von hier aus arbeiten beide Mitglieder des Paares sowohl am Produktionscode als auch am Testcode, wobei sich eine Person auf jeden Aspekt konzentriert und Möglichkeiten zur Verbesserung des Produktionscodes sowie des dahinter stehenden Testcodes bespricht.

Ich sehe keinen Vorteil darin, jedem Paar zwei Merkmale zu geben. Was Sie am Ende haben würden, ist etwas, das TDD für einige Funktionen ähnelt, und etwas, das TDD für andere Funktionen nicht entspricht. Sie verlieren den Fokus. Sie profitieren nicht von Peer Review in Echtzeit. Sie erhalten keine der wichtigsten Vorteile der Kopplung.

Bei der Paarprogrammierung geht es nicht um Geschwindigkeit, sondern um Qualität. Der Versuch, eine modifizierte Technik zu verwenden, bei der es darum geht, schneller zu werden, widerspricht also der Natur. Indem Sie durch parallele Codeüberprüfung und Testentwicklung qualitativ hochwertigere Software entwickeln, sparen Sie Zeit, da mindestens zwei Personen über jede Änderung Bescheid wissen und Sie Wartezyklen für Peer Review und Test vermeiden (oder verkürzen).

Das Hauptproblem bei Ihrer Idee ist, dass Sie nicht einfach Tests für jeden Code schreiben können. Der Code muss testbar sein.

Das heißt, Sie müssen in der Lage sein, Mocks zu injizieren, das zu testende Bit zu trennen, auf den geänderten und zu bestätigenden Status zuzugreifen usw.

Wenn Sie kein Glück haben oder den Test nicht zuerst schreiben, bedeutet das wahrscheinlich, dass Sie den Code ein wenig umschreiben. Wenn Sie nicht derjenige sind, der den Code an erster Stelle schreibt, bedeutet dies Verzögerung, Besprechungen, Umgestaltung usw

Das Hauptproblem, das ich hier sehe: Wenn ich Code schreibe, möchte ich ihn kompilieren und ausführen und die augenfälligsten Fehler sofort entfernen - auch wenn der Code unvollständig ist und ich weiß, dass das Gerät, die Funktion oder das Merkmal vorhanden sind nur teilweise umgesetzt. Und um den Code einer Unit auszuführen, benötige ich ein Programm, das die Implementierung aufruft, normalerweise einen Unit-Test oder zumindest einen Teil-Unit-Test. Dies ist nicht notwendigerweise "TDD-Stil nach dem Buch", ein solcher Test kann nach oder vor dem zu testenden Code geschrieben werden.

Wenn eine Version meines Geräts "funktionsfähig" und frei von allen Fehlern ist, die ich selbst finden kann, ist es sinnvoll, sie einer zweiten Person zu übergeben und sie / ihn zusätzliche Einheitentests schreiben zu lassen oder meinen Code zu überprüfen . Aber für mich macht es keinen Sinn, es abzugeben, sobald der Compiler keine Warnungen anzeigt, das ist definitiv zu früh, wenn ich weiß, dass ich dem Tester im Detail Dinge erklären musste, die "noch" nicht funktionieren oder funktionieren werden anders in zwei Stunden, da ich immer noch an diesem Stück Code arbeite. Der dafür notwendige Kommunikationsaufwand auf dieser Detailebene würde meiner Meinung nach nicht durch die Vorteile ausgeglichen.

Also ja, ein zweites dev Schreiben mit zusätzlichen Sinn macht Unit - Tests, aber nicht zum Schreiben der Unit - Tests ausschließlich .

Es scheint die Möglichkeit zu geben, dass eine der folgenden Situationen eintritt, die alle unerwünscht sind:

Verwechslung

Wie Ewan ausführte, muss der CUT möglicherweise geändert werden, damit er testbar ist. Der Grund für die Änderung ist für den Entwickler nicht immer offensichtlich (und kann zu Meinungsverschiedenheiten führen), weshalb Tests zuerst geschrieben werden.

Streit

Entwickler A hat möglicherweise seinen Code fertiggestellt und möchte, dass er getestet wird. Entwickler B entwickelt möglicherweise auch und kann daher gezwungen sein, seinen Code zu parken, um an den Komponententests teilzunehmen.

Kontextwechsel

Auch wenn Entwickler B bereit ist, seine Entwicklung zurückzustellen, um den von Entwickler A geschriebenen Code zu testen - die Änderung der Aktivität ist mit Kosten verbunden.

Es ist seit Jahrzehnten anerkannt, dass die Verdoppelung der menschlichen Kraft die Entwicklungszeit nicht halbiert. In Anbetracht der Faktoren, die ich oben skizziert habe, ist es schwer zu sehen, wie diese Anordnung die Dinge verbessern würde.

In Verbindung mit Pair Programming und TDD wird dies als Ping Pong Pattern bezeichnet :

• A schreibt einen neuen Test und stellt fest, dass er fehlschlägt.
• B implementiert den Code, der zum Bestehen des Tests erforderlich ist.
• B schreibt den nächsten Test und stellt fest, dass er fehlschlägt.
• A implementiert den Code, der zum Bestehen des Tests erforderlich ist.

Und so weiter. Refactoring wird immer dann durchgeführt, wenn der Bedarf des Fahrers besteht.

Aber Sie scheinen beiden Programmierern vorzuschlagen, mit unterschiedlichen Computern zu programmieren. Für eine getrennte Ausführung ist eine sehr niedrige Spezifikation erforderlich. Dies widerspricht agilen Metodologien. Jede Änderung müsste koordiniert werden. In TDD machen Sie das Low-Level-Design im Handumdrehen und es ist kein Problem. Ich gehe davon aus, dass für Ihren Ansatz eine Art Skelett bereits codiert sein muss.

Wie auch immer: Sie können viel lernen, indem Sie neue Methoden ausprobieren, auch wenn diese nicht zu 100% effizient sind. Sie können es testen und Ihre realen Erfahrungen teilen

Ich komme zu spät zu dieser Party, aber ich glaube, ich muss noch etwas hinzufügen.

Wird es bereits als unbekannte Methode beschrieben und in der Softwareentwicklung verwendet?

Sie beschreiben Peer Testing .

Nehmen wir an, wir haben Entwicklerpaare.

Ah, gute alte Pair-Programmierung .

Jedes Paar ist für einen Teil des Codes verantwortlich. Einer aus dem Paar implementiert eine Funktion (Schreiben von Code) und der zweite schreibt einen Komponententest dafür. Tests werden nach Code geschrieben. In meiner Vorstellung helfen sie sich gegenseitig, arbeiten aber eher getrennt.

Das ist keine Pair-Programmierung.

Im Idealfall würden sie an zwei Features ähnlicher Größe arbeiten und diese dann zur Testvorbereitung austauschen.

Das ist definitiv Peer Testing. Hier ist ein ACM-Artikel darüber . Ich habe das getan. Ich habe dort gearbeitet, wo es ein formaler Bestandteil des Peer Review war Prozesses war. Es ist hilfreich, aber sicherlich nicht als erste Testreihe gedacht, und es ist sicherlich keine klassische Paarprogrammierung.

Ein anderer Name dafür ist Whitebox Testing . Obwohl sich diese Definition nicht darauf bezieht, wer die Tests durchführt, sondern darauf, dass der Tester das Innenleben des zu testenden Objekts sieht, im Gegensatz zu Black-Box-Tests, bei denen nur der Inhalt und die Inhalte angezeigt werden was geht raus Black Box ist in der Regel das, was QA tut.

Die erste Testlinie liegt fest in der Hand des Programmierers. Wenn nicht, bitten Sie mich, meinen Code nicht selbst zu testen, was ich rundweg ablehne. Ich habe meinen Code getestet, seit ich 10 Jahre alt war. Ich habe damals vielleicht nicht mit ausgefallenen Unit-Tests getestet, aber mein Code wurde getestet. Es wurde jedes Mal getestet, wenn ich es laufen ließ.

Was ich von einem Peer-Tester erwarte, sind Tests, die meine Tests ergänzen. Tests, die die Probleme deutlich machen, die der Peer beim Überprüfen des Codes festgestellt hat. Durch das Ausdrücken dieser Probleme mit einem automatisierten Test wird das Verstehen ihrer Bedeutung erheblich erleichtert. Tatsächlich habe ich technische Gespräche mit Kollegen geführt, die meinen Standpunkt einfach nicht erkennen konnten, und dann festgestellt, dass es das beste Mittel ist, ihnen zu zeigen, dass das Problem darin besteht, einen Komponententest zu schreiben. Das ist Peer Testing.

Nun, wenn Sie mir Tests schreiben möchten, bevor ich meinen Code gut schreibe. Nichts ist vergleichbar mit einem Anforderungsdokument, das so formal ist, dass es kompiliert wird.

Ich habe DDT (Development Driven Testing, auch bekannt als Tests After Code), Pair Programming und Red-Green-Refactor TDD für jeweils mehrere Jahre durchgeführt. So antworten Sie Punkt für Punkt auf Ihre Behauptungen:

Tests werden von jemandem geschrieben, der mehr über die Implementierung sehen kann

Die Person, die Tests schreibt, muss die Implementierung so gut wie möglich kennen, um Tests mit einer guten Abdeckung ohne Überprüfung zu schreiben. Das klassische Beispiel hierfür ist das Testen mit drei Eingängen, wenn zwei beweisen, was Sie testen möchten. Während sie durch das Lesen des Codes eine Vertrautheit mit dem Code auf der Oberfläche erreichen können, können sie nicht genau verstehen, was der ursprüngliche Entwickler durchlaufen hat, um den aktuellen Status zu erreichen. Sie werden also den Code nicht optimal verstehen.

Die Arbeit sollte etwas schneller als die Paarprogrammierung sein (zwei Funktionen gleichzeitig)

Ich verstehe nicht, warum du das sagst. Während jemand Tests schreibt, arbeitet er nicht an neuen Funktionen. Sie können die Arbeitsfähigkeit eines Menschen nicht auf magische Weise verdoppeln, indem Sie ihm zwei verschiedene Arten von Arbeit geben. Nach meiner Erfahrung ist das Schreiben von Tests im Allgemeinen schwieriger als das Schreiben von Produktionscode. Sie könnten also definitiv nicht produktiv und verantwortungsbewusst an Tests für einen Code arbeiten, während Sie eine andere Funktion schreiben.

Sowohl für Tests als auch für Code ist eine verantwortliche Person zuständig

Zuerst Tests sind Code. Für das Unternehmen ist der Testcode fast so wichtig wie der Produktionscode, da er es dem Unternehmen ermöglicht , die Software ohne Angst zu ändern. Zweitens unterscheidet sich dies nicht von einer Person, die die Tests und den Produktionscode schreibt, oder sogar von einem Paar, das beide schreibt.

Code wird von mindestens zwei Personen getestet

Nein, es wird nur von der Person getestet, die den Test schreibt. Wenn Sie nicht noch mehr Zeit für das Testen verwenden möchten, warum sollten Sie dann bei zwei aufhören?

Vielleicht würde die Suche nach Fehlern in Code, der von einer Person geschrieben wurde, die Ihren Code testet, eine besondere Motivation für das Schreiben von besserem Code und das Vermeiden von Schnitten geben.

Entwickler (auch ältere) haben sehr unterschiedliche Vorstellungen, was "guten" Code ausmacht. Der eckpfeiler einer Person ist die absolut gültige Methode einer anderen Person, um so schnell wie möglich zum Arbeitscode zu gelangen. Dies ist ein Rezept für die Schuld und für das Spielen des Systems.

Rot-Grün-refactor TDD ( eigentlich einen einzigen Test zu schreiben , bevor die Produktion Code zu schreiben, es läuft, sieht es nicht, Modifizieren der Produktionscode nur, den Test erneut ausgeführt wird , sieht es gelingen, und dann Refactoring, und nicht das Überspringen oder tauschen alle Diese Schritte) und Codeüberprüfungen funktionieren.

Ich denke, dass diese Idee einige Vorteile hat:

Sie werden einzeln durchlaufen.

Tests werden von jemandem geschrieben, der mehr über die Implementierung sehen kann,

Sie meinen also, dass der erste Entwickler einige Zeit damit verbracht hat, eine Implementierung zu schreiben, von der er nicht sicher ist, ob sie funktioniert. Dann kommt ein anderer Entwickler und schreibt Tests. Dabei stützt er sich auf den Code, von dem niemand weiß, ob er korrekt ist, und hofft, dass er einen taktischen Vorteil gegenüber dem Schreiben von Tests bietet, wenn es nur darum geht, was der Code tun soll. Wenn die Implementierung fehlerhaft ist, hilft sie meiner Meinung nach beim Schreiben von Tests nicht weiter.

Die Arbeit sollte etwas schneller als die Paarprogrammierung sein (zwei Funktionen gleichzeitig)

Sobald beide Entwickler ihre anfängliche Entwicklung abgeschlossen haben, weiß niemand, ob einer ihrer Codes korrekt ist. Dies muss noch überprüft werden, niemand kann einen Punkt als erledigt abhaken und niemand kann vorhersagen, wann er erledigt sein wird. Vergleichen Sie dies mit TDD: Sie schreiben den Test zuerst, lassen ihn dann fehlschlagen und bestehen ihn mit Code. Das ist Code, der immer mehr Szenarien unterstützt. Das ist Vorwärtsbewegung.

Wenn Sie sie parallel weiterentwickeln, wird Code, der in beiden Features wiederverwendet werden kann, zweimal geschrieben und kostet zweimal mehr.

Beide Tests und der Code haben die verantwortliche Person dafür.

Untersuchen Sie den Besitz von kollektivem Code, wie von XP vorgeschlagen. Sie werden noch mehr Leute haben, die für den Code verantwortlich sind. Wenn es Ihr Ziel ist, Wissen zwischen Entwicklern auszutauschen, warum versuchen Sie dann, diese voneinander zu trennen?

Code wird von mindestens zwei Personen getestet

Mit Paar TDD auch. Beim Pairing müssen beide Personen zustimmen, dass der geschriebene Code angemessen ist oder nicht. Wenn dies zu einem Kampf führt, haben einige Leute im Team ein falsches Ego-Problem.

Vielleicht würde die Suche nach Fehlern in Code, der von einer Person geschrieben wurde, die Ihren Code testet, eine besondere Motivation für das Schreiben von besserem Code und das Vermeiden von Schnitten geben.

Die Suche nach Fehlern impliziert, dass Sie es irgendwann toleriert haben, dass sie hereinkommen. Wenn sie hereinkommen, werden sie nicht bemerkt. Wenn Sie sich weigern, zuerst Tests zu schreiben, erhalten Sie die Lizenz für Fehler, die eingehen müssen.

Schneidecken können unbeabsichtigt sein. Dafür ist Pair Programming gedacht. Jedes Mitglied des Paares sollte angewiesen werden, sich nicht von dem anderen abschneiden zu lassen, denn das machen wir alle. Das erfordert, dass Sie Ihren Stolz im Schrank lassen und ihn zurücknehmen, wenn Sie das Büro verlassen. Wenn Sie erwarten, dass Ihre Leute stets streng sind, denken Sie nicht über die allgemeine Situation nach und machen sich bereit für einen Misserfolg.

XP sagt ausdrücklich, dass alle Praktiken, aus denen XP besteht, sich gegenseitig verstärken, indem sie die Mängel des jeweils anderen abdecken. Sie sollten sich keine Kritik an XP-Übungen anhören, die von den anderen getrennt sind. Keine Übung ist perfekt, TDD ist nicht perfekt, Paarprogrammierung ist nicht perfekt, kollektiver Code-Besitz ist nicht perfekt, aber alle decken sich gegenseitig ab.