Adversarial / Naive Pairing with TDD: Quanto è efficace?

Question

Un mio amico stava spiegando come fanno l'accoppiamento di ping-pong con TDD sul suo posto di lavoro e ha detto che prendono un "contraddittorio". approccio. Cioè, quando la persona che scrive il test consegna la tastiera all'implementatore, l'imprenditore cerca di fare la cosa più semplice (e talvolta sbagliata) per far passare il test.

Ad esempio, se stanno testando un metodo GetName () e il test verifica " Sally " ;, l'implementazione del metodo GetName sarebbe semplicemente:

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

Che, ovviamente, supererebbe il test (ingenuamente).

Spiega che ciò aiuta ad eliminare i test ingenui che controllano specifici valori fissi anziché testare il comportamento effettivo o lo stato previsto dei componenti. Aiuta anche a guidare la creazione di più test e, in definitiva, un design migliore e meno bug.

Suonava bene, ma in una breve sessione con lui, sembrava che ci volesse molto più tempo per superare un singolo round di test rispetto al resto e non pensavo che fosse guadagnato molto valore extra.

Usi questo approccio e, in tal caso, l'hai visto ripagare?

Answer 1

Si basa sulla personalità della squadra. Ogni squadra ha una personalità che è la somma dei suoi membri. Devi stare attento a non praticare implementazioni passive-aggressive fatte con un'aria di superiorità. Alcuni sviluppatori sono frustrati da implementazioni come

  

return " Sally " ;;

Questa frustrazione porterà a una squadra senza successo. Ero tra i frustrati e non l'ho visto ripagare. Penso che un approccio migliore sia una comunicazione più orale che dia suggerimenti su come un test potrebbe essere meglio implementato.

Answer 2

Può essere molto efficace.

Ti costringe a pensare di più a quale test devi scrivere per fare in modo che l'altro programmatore scriva la corretta funzionalità richiesta.

Costruisci il codice pezzo per pezzo passando frequentemente la tastiera

Può essere piuttosto faticoso e richiedere molto tempo, ma ho scoperto che è raro che ho dovuto tornare indietro e correggere un bug in qualsiasi codice che è stato scritto in questo modo

Answer 3

Ho usato questo approccio. Non funziona con tutte le coppie; alcune persone sono naturalmente resistenti e non gli daranno un'onesta possibilità. Tuttavia, ti aiuta a fare correttamente TDD e XP. Vuoi provare ad aggiungere funzionalità alla tua base di codice lentamente. Non vuoi scrivere un enorme test monolitico che richiederà molto codice per soddisfare. Vuoi un sacco di semplici test. Devi anche assicurarti di passare la tastiera avanti e indietro tra le tue coppie regolarmente in modo che entrambe le coppie siano impegnate. Con l'accoppiamento contraddittorio, stai facendo entrambe le cose. Test semplici portano a implementazioni semplici, il codice viene creato lentamente ed entrambe le persone sono coinvolte durante l'intero processo.

Answer 4

Mi piace qualche volta, ma non uso quello stile per tutto il tempo. Agisce come un bel cambio di ritmo a volte. Non penso che mi piacerebbe usare lo stile per tutto il tempo.

Ho trovato uno strumento utile con i principianti per introdurre come i test possono guidare l'implementazione.

Answer 5

(Innanzitutto, il TDD Avversario dovrebbe essere divertente. Dovrebbe essere un'opportunità per insegnare. Non dovrebbe essere un'opportunità per i rituali di dominazione umana. Se non c'è spazio per un po 'di umorismo, allora lascia la squadra Mi dispiace, la vita è a corto di sprechi in un ambiente negativo.)

Il problema qui è rappresentato da test con nomi errati. Se il test era simile al seguente:

foo = new Thing("Sally")
assertEquals("Sally", foo.getName())

Quindi scommetto che è stato chiamato " testGetNameReturnsNameField " ;. Questo è un brutto nome, ma non immediatamente, ovviamente. Il nome proprio per questo test è " testGetNameReturnsSally " ;. Questo è quello che fa. Qualsiasi altro nome ti sta cullando in un falso senso di sicurezza. Quindi il test è chiamato male. Il problema non è il codice. Il problema non è nemmeno il test. Il problema è il nome del test.

Se, invece, il tester avesse chiamato il test " testGetNameReturnsSally " ;, allora sarebbe stato immediatamente ovvio che questo probabilmente non sta testando ciò che vogliamo.

È quindi dovere dell'attore dimostrare la cattiva scelta del tester. È inoltre dovere dell'attore scrivere solo ciò che i test richiedono loro.

Tanti bug nella produzione non si verificano perché il codice ha fatto meno del previsto, ma perché ha fatto di più. Sì, ci sono stati test unitari per tutti i casi previsti, ma non c'erano test per tutti i casi limite speciali che il codice ha fatto perché il programmatore ha pensato: "È meglio che lo faccia anche io, probabilmente avremo bisogno di questo". e poi me ne sono dimenticato. Ecco perché TDD funziona meglio di test-after. Ecco perché buttiamo via il codice dopo un picco. Il codice potrebbe fare tutto ciò che vuoi, ma probabilmente fa qualcosa di cui pensavi di aver bisogno, e poi ti sei dimenticato.

Forza lo scrittore di test a testare ciò che vuole veramente. Scrivi solo codice per superare i test e non di più.

RandomStringUtils è tuo amico.