Paio di programmazione e test delle unità

La tua domanda è ortogonale al tuo problema. Attaccare due programmatori che non vogliono o non possono scrivere insieme buoni test unitari non ti porterà più / migliori test unitari.

Attaccare un programmatore che è povero nello scrivere test unitari con uno buono può proporti buone abitudini, ma potrebbe non essere una buona coppia per altri motivi (il test unitario è solo una parte dell'intero processo di sviluppo dopo tutto). Ci sono altre domande / post che trattano i vantaggi e i problemi della programmazione di coppia.

Il tuo obiettivo dovrebbe essere quello di cambiare la cultura che ha causato il problema in primo luogo. Una buona programmazione della coppia può essere d'aiuto, ma di solito richiede una combinazione di cose che spingono verso quell'obiettivo finale. Non esiste un proiettile d'argento (gioco di parole) per far scrivere alle persone buoni test unitari.

Dalla mia esperienza personale come membro del team che ha attraversato un processo simile, la scelta della programmazione a coppie e del TDD è stata di grande successo e utile. La nostra copertura è aumentata in modo significativo.

Ciò che abbiamo fatto è stato:

• coppie di forze per il codice di produzione. Non è stato possibile eseguire il commit di codice se non è stato creato in coppia.
• forza TDD, non è stato possibile eseguire il commit di codice se non TDDed.

All'inizio era difficile e lento (alcune settimane, circa un mese e mezzo), ma è diventato molto pratico e naturale.

EDIT: Ovviamente abbiamo avuto una copertura del codice molto alta e un nuovo codice, e abbiamo rifattorizzato il vecchio codice e aggiunto il test lentamente. Quando una vecchia classe / modulo doveva essere modificata, abbiamo aggiunto test e modifiche. Gradualmente la copertura è diventata piuttosto buona a livello dell'intero progetto.

Infine, dopo essere stati abituati a entrambi i processi, la natura obbligatoria dei 2 processi è stata rimossa e ora la maggior parte del tempo è naturale (circa il 90%) ma commettiamo anche cose semplici fatte singole o senza TDD.

C'è un modo più semplice per ottenere una copertura più elevata. È sufficiente stabilire una regola per la quale non è possibile eseguire il commit di codice a meno che non sia coperto da una quantità di test sufficiente (ciò che sufficiente significa comunque un'altra storia). Naturalmente la programmazione della coppia potrebbe essere d'aiuto, ma non è garantito che quando la tua coppia è composta da due persone riluttanti alla prova , improvvisamente produrranno un codice pesante per test (direi che è molto probabile che lo faranno attenersi al loro test-riluttanza insieme).

Per la cronaca, costringere le persone a scrivere test potrebbe portare a test molto scarsi, il che è contrario a ciò che si vuole ottenere. Penso che potrebbe essere una buona idea pre-assegnare le coppie , es. persona sensibile al test con persona riluttante , in modo che la prima possa aiutare e spiegare perché le cose vengono gestite in un certo modo per il dopo.

Se i tuoi progetti sono grandi, un team di test separato è la strada da percorrere. La maggior parte delle grandi aziende di software ha squadre di test separate.

La programmazione accoppiata migliora la qualità del codice, ma presenta un grosso problema potenziale: alla maggior parte dei dirigenti non piace e non tenterà di impedirlo. Pensano di pagare due persone per fare il lavoro di uno.

Modifica dopo aver letto il commento di @Giorgio:

"Non dovresti testare il tuo codice", è vero. Lavorare sapendo che altre persone metteranno alla prova, significa che devi programmare secondo gli standard accettati. No tipo di logica "Capisco il mio pasticcio".

In effetti, Pair Programming non ti aiuterà. Il principale vantaggio della programmazione della coppia è di diffondere o combinare le conoscenze per risolvere alcuni problemi.

Il test "disciplina" è un enorme nuovo universo. Abbiamo un sacco di approcci per fare test, ed è un processo lungo tempo. Se la tua azienda non ha tempo, denaro e datori di lavoro per implementare un buon processo di test, un team di test esterno può essere la soluzione praticabile.

Se si conosce che la copertura del test dell'unità è bassa, è necessario utilizzare uno strumento di copertura. Perché non miri solo ai pezzi di codice in evidenza e scrivi test unitari per loro?