L'unica cosa più importante da insegnare durante l'insegnamento del TDD [chiuso]

Question

Sto collaborando con un gruppo di professionisti per organizzare un evento per aiutare a insegnare la pratica del TDD a persone interessate, ma che non hanno esperienza (novizi).

Stiamo cercando di escogitare laboratori, seminari, ecc. e sto cercando di pensare all'unica, più grande cosa che dobbiamo impartire a questi individui per aiutarli ad avere successo nella pratica del TDD in futuro.

Cosa diresti che dovremmo dare la priorità all'apprendimento? Quale aspetto dell'insegnamento del TDD è il più importante. Se devi fare due cose, va bene, non ti trattengo nella parte SINGOLA :)

Answer 1

Riguarda il design . Riguarda NON i test.

Answer 2

Non saltare i passaggi del processo. Ci vuole più tempo per entrare nel groove iniziale di TDD, ma una volta che è in atto l'intero SDLC è più veloce e molto più privo di bug.

Rosso - Verde - Rifattore - > fallo e basta.

Answer 3

Solo perché i tuoi test superano ciò non significa che il codice sia corretto.

A parte questo, direi che è importante considerare i test nel tuo progetto. Se è difficile testare il codice senza una conoscenza approfondita dell'implementazione interna dell'unità in prova, è possibile riconsiderare il progetto. Altrimenti, il refactoring diventa più soggetto al rischio perché è probabile che i test debbano essere modificati con il codice.

Answer 4

Non so se questo sarebbe considerato la cosa più importante, ma è stato qualcosa che mi ha richiesto del tempo per "ottenere" quando stavo esplorando per la prima volta usando TDD.

Non scrivere il codice nella tua testa prima di scrivere il test.

Quando ho iniziato a fare TDD, lo sapevo " quale dovrebbe essere il design. "Sapevo" quale codice volevo scrivere. Quindi ho scritto un test che mi avrebbe permesso di scrivere quel pezzetto di codice.

Quando stavo facendo questo non stavo davvero facendo TDD - dato che stavo scrivendo prima il codice (anche se il codice era solo nella mia testa :-)

Mi ci è voluto un po 'di tempo (e un po' di frugando da gente intelligente) per rendermi conto che devi concentrarti sul test. Scrivi il test per il comportamento desiderato, quindi scrivi il codice minimo necessario per farlo passare, quindi lascia che il progetto emerga attraverso il refactoring. Ripeti fino al termine.

Answer 5

Suggerisco, " Sii paziente. " Sembra strano all'inizio. Per me, erano probabilmente tre progetti prima che iniziasse a sembrare naturale.

Answer 6

Sono d'accordo con cosa Jon ha detto nella sua risposta , ma penso che un corollario importante sia che la testabilità non impone " buon design ", ma è solo un indicatore che il tuo design sia sul bersaglio.

Answer 7

TDD, nella mia mente, è tutto incentrato sul ritmo (rosso, verde, refattore). Abbassare il ritmo ti porta oltre la "gobba" di "non ottenerlo". E se non riesci a ridurre il ritmo, probabilmente non rimarrai con il TDD per molto tempo. L'essenza del ritmo sono i piccoli passi, che è già stato menzionato. Scrivi il minor codice possibile e rifletti senza pietà.

Una cosa da enfatizzare è che TDD scambia alcuni guadagni a breve termine con quelli a lungo termine. Iniziare con TDD ridurrà invariabilmente la tua produttività. Ma una volta che impari il ritmo, è come entrare in un groove e può effettivamente aiutarti a lavorare più velocemente. Per non parlare dell'effetto collaterale del TDD è una base sempre crescente di test unitari che forniscono test di regressione. Una inevitabilità del software è che i sistemi gestiti (senza una serie di test di regressione automatizzati) si degradano nel tempo.

Answer 8

Sottolinea che TDD è un cambio di paradigma per gli sviluppatori . Se stai schierando una nuova squadra, renditi conto che ci vorranno fino a sei mesi per rendere la squadra pienamente efficace come praticanti TDD. Una volta che hai un team agile maturo che pratica efficacemente il TDD, l'associazione consentirà a un nuovo sviluppatore di entrare nel vivo dopo un paio di iterazioni. Inoltre, usando le coppie di una squadra per seminare una nuova linea, puoi far accelerare la nuova linea su TDD molto più velocemente della prima linea.

Nei progetti che abbiamo misurato, abbiamo visto un calo di sei volte dei difetti riscontrati durante il test funzionale / di regressione automatizzato una volta che il team ha imparato a fare TDD. Questo è un risparmio significativo. Inoltre, il codice riflette un design più pulito, con meno righe di codice per ogni funzione. TDD ma un arresto virtuale alla doratura. TDD è più efficace se le tue carte storia hanno criteri di accettazione.

TDD consente anche un ritmo sostenibile. Il team scoprirà di poter continuare a ottenere lo stesso numero di funzionalità con ciascuna iterazione poiché il codice rimane pulito con pochi difetti. Sia con TDD sia con test funzionali / di regressione automatizzati, durante il Test di accettazione dell'utente vengono spesso rilevati zero difetti.

Answer 9

Far fronte alla pressione di abbandonare il TDD quando le scadenze si stanno restringendo. Questo è uno dei maggiori problemi che ho riscontrato aiutando persone e team con TDD. Hanno avuto problemi nell'esprimere l'importanza e il valore del rilascio in primo piano invece dei test per i dirigenti.

Answer 10

Procedi a piccoli passi.

Assicurati che i tuoi test coprano solo un ambito molto piccolo e, come dice PhlipCPP: ' Esegui la MODIFICA MINIMA necessaria per far passare il test. '

Anche così, c'è molto da TDD, quindi devi comunque assicurarti di non perdere nulla.

Answer 11

Nella mia esperienza, l'uso di TDD consente a me e al mio team di riformattare senza pietà il nostro codice senza preoccuparci che ciò rompa qualcosa di inaspettato.

Quindi immagino per me l'aspetto più importante del TDD è la copertura, poiché una buona copertura mi dà la sicurezza di refactoring ogni volta che vedo un punto nella base di codice che può usarlo.

Answer 12

Enfatizza diversi tipi di test. Sia i test in black box che quelli in white box sono importanti e hanno scopi diversi. Il test in white box non è lì per verificare la correttezza perché non può testare l'intero sistema. È lì per rendere gli odori di codice ancora più puzzolenti e quindi fornire una migliore direzione di refactoring. Il test della scatola nera è lì per testare la correttezza. Ogni funzionalità dovrebbe essere testata in black box.

Inoltre, sottolinea le differenze nella copertura del test. A causa di problemi combinatori e di ripetibilità, è impossibile testare in black box ogni percorso di codice nell'applicazione. La mia regola è che una funzionalità non è completa fino a quando non viene testata in black box. Dovresti aiutare gli studenti a capire le proprie regole. Tuttavia, i test in white box non dovrebbero avere dipendenze di classe esterne; pertanto ogni riga di ogni classe dovrebbe essere testata in white box.