2008-09-19 9 views
4

Ein Freund von mir erklärte an seinem Arbeitsplatz, wie sie Ping-Pong-Pairing mit TDD machen und er sagte, dass sie einen "gegnerischen" Ansatz verfolgen. Das heißt, wenn die testende Person die Tastatur an den Implementierer übergibt, versucht der Implementierer, die einfachste (und manchmal falsche) Sache zu machen, um den Test bestehen zu lassen.Adversarial/Naive Pairing mit TDD: Wie effektiv ist es?

Zum Beispiel, wenn sie Testen einer Methode getName() und die Testprüfungen für „Sally“, die Umsetzung der GetName-Methode würde einfach sein:

public string GetName(){ 
    return "Sally"; 
} 

Welche wäre natürlich, Pass der Test (naiv).

Er erklärt, dass dies hilft, naive Tests zu eliminieren, die nach bestimmten Werten suchen, anstatt das tatsächliche Verhalten oder den erwarteten Zustand der Komponenten zu testen. Es trägt auch dazu bei, mehr Tests zu erstellen und letztendlich das Design und die Anzahl der Fehler zu verbessern.

Es hörte sich gut an, aber in einer kurzen Sitzung mit ihm schien es viel länger zu dauern, um eine einzige Runde von Tests zu absolvieren als sonst und ich hatte nicht das Gefühl, dass viel zusätzlicher Wert gewonnen wurde.

Verwenden Sie diesen Ansatz, und wenn ja, haben Sie gesehen, dass es sich auszahlt?

Antwort

0

Es basiert auf der Persönlichkeit des Teams. Jedes Team hat eine Persönlichkeit, die die Summe seiner Mitglieder ist. Sie müssen aufpassen, dass Sie keine passiv-aggressiven Implementierungen mit Überlegenheit üben. Einige Entwickler sind frustriert von Implementierungen wie

return "Sally";

Diese Frustration wird zu einem erfolglosen Team führen. Ich war unter den frustrierten und sah es nicht auszahlen. Ich denke, ein besserer Ansatz ist mehr mündliche Kommunikation, die Vorschläge macht, wie ein Test besser umgesetzt werden könnte.

+0

Ich kann sehen, dass die Leute wütend darüber werden, aber zumindest in der Mannschaft dieses Kerls waren sie Freunde und sie erkannten, dass sie keine Klugscheißer waren und nur versuchten, die bestmöglichen Tests durchzuführen könnte, so hat es gut für sie funktioniert – chadmyers

1

Ich habe diesen Ansatz verwendet. Es funktioniert nicht mit allen Paaren; Manche Menschen sind einfach von Natur aus resistent und geben ihr keine ehrliche Chance. Es hilft Ihnen jedoch, TDD und XP richtig zu machen. Sie möchten der Codebase langsam Funktionen hinzufügen. Sie möchten keinen riesigen monolithischen Test schreiben, der viel Code braucht, um zufrieden zu stellen. Sie wollen eine Reihe einfacher Tests. Sie sollten auch sicherstellen, dass Sie die Tastatur regelmäßig zwischen Ihren Paaren hin und her bewegen, so dass beide Paare aktiviert sind. Mit adversarial Paarung, machst du beides. Einfache Tests führen zu einfachen Implementierungen, der Code wird langsam aufgebaut und beide Personen sind während des gesamten Prozesses involviert.

0

Ich mag es manchmal - aber benutze diesen Stil nicht die ganze Zeit. Ist manchmal eine nette Abwechslung. Ich glaube nicht, dass ich den Stil die ganze Zeit benutzen möchte.

Ich habe es ein nützliches Werkzeug mit Anfängern gefunden, um einzuführen, wie die Tests die Implementierung zwar vorantreiben können.

2

Es kann sehr effektiv sein.

Es zwingt Sie, mehr darüber nachzudenken, welchen Test Sie schreiben müssen, damit der andere Programmierer die richtige Funktionalität schreibt, die Sie benötigen.

Sie bauen den Code Stück für Stück nach oben auf der Tastatur vorbei häufig

Es kann ziemlich anstrengend und zeitraubend sein, aber ich habe festgestellt, dass seine selten habe ich wieder zu kommen hatte und einen Fehler in jedem Code zu beheben, hat So geschrieben

+1

+ 1 Ich habe das auch gefunden. Es gab viel weniger von der "Happy-Path-Analyse", auf die man beim Programmieren leicht fallen kann. – Grundlefleck