Il test e la correzione devono essere scritti da persone diverse?

Non è necessario che il test e il codice vengano scritti da 2 set distinti per raggiungere questo obiettivo.

TDD dovrebbe essere guidato da ATDD (test di accettazione) - i test di accettazione sono scritti dal cliente / qa per garantire che la soluzione sia la cosa giusta. Per farli passare, gli sviluppatori usano TDD per sviluppare l'implementazione. Potresti iniziare con una lista di prova su un pezzo di carta prima di arrivare alla tastiera (come suggerisce Kent Beck nei suoi libri). Inoltre, si raccomanda di lavorare a coppie, in modo che ci sia una maggiore possibilità che eventuali errori vengano rilevati in precedenza. Se si desidera coinvolgere un tester mentre si presenta la lista di test, va bene, tuttavia credo che gli sviluppatori dovrebbero essere completi e in grado di identificare tutti gli scenari da soli.

Tutti i passaggi di TDD dovrebbero essere fatti dalla stessa persona / coppia. Suddividere quel lavoro aumenterà la necessità di perdita di comunicazione / informazione. Scrivere test è un'attività non banale - l'atto stesso guida il design dei tuoi oggetti.

Mi sembra che tu stia descrivendo il link ; una coppia che lavora su una funzione alterna quale membro della coppia guida la scrittura del test e implementa il codice per fare passare il test.

Ho trovato utile assicurarsi che entrambi i membri della coppia trascorrano un tempo adeguato di guida. Inoltre, aiuta a rafforzare la condivisione delle conoscenze all'interno della coppia piuttosto che consentirne lo sviluppo a uno specialista di test e uno specialista dell'implementazione.

C'è una convinzione che dividere sviluppatori e tester aiuta a creare un prodotto migliore, perché i tester possono aiutare a "spingere" gli sviluppatori impostando standard più elevati per loro. A volte, gli sviluppatori ridurranno la qualità dei loro casi di test al fine di evitare di dover correggere bug del caso limite.

Probabilmente si tratta di quanto bene il tuo team lavora insieme. Se vanno d'accordo, le critiche dei tester saranno probabilmente costruttive. Se i membri ora lavorano bene insieme, la tensione tra i due gruppi ostacolerà il progetto. I tester potrebbero sabotare gli altri membri con test ridicoli che fanno sembrare che gli sviluppatori non soddisfano le specifiche (e i tester sono così brillanti da aver pensato a un caso di test così pazzo).

TDD prevede un ciclo di feedback molto breve tra test e codice, nell'ordine dei secondi o dei minuti. L'unico modo in cui ciò sarebbe fattibile per persone diverse è attraverso l'accoppiamento ping pong, come accennato. Ci può essere un vantaggio nel dividere il lavoro di test tra dev e test in altri paradigmi, ma con TDD semplicemente non è fattibile. Fortunatamente, non è nemmeno necessario.

Questo tipo di test (test unitari) dovrebbe essere fatto dalla stessa persona / coppia che scrive effettivamente il codice.

L'esecuzione del test è spesso integrata con la compilazione - quindi è perfettamente logico che chiunque stia scrivendo / compili faccia anche questo tipo di test.

Questo tipo di test unitari sono talvolta definiti test dei programmatori che evidenziano chi dovrebbe scriverli / eseguirli.