Rivedi prima i test

IMHO sembra molto simile a un modello di sviluppo a cascata, in cui le specifiche degli anni '80 sono state sostituite con Test. Ad esempio, "È necessario completare il passaggio X prima di poter iniziare il passaggio Y". "Dev scrive design e ogni altro dev può implementare" ... Sono quasi sicuro che nel mondo reale non riuscirà a fornire un buon prodotto e produttività. Troppo tempo sarà sprecato per fare test "perfetti", lasciando non abbastanza tempo per scrivere codice robusto e di qualità. Non appena si imposta l'aspettativa che gli sviluppatori siano intercambiabili come gli operai del cantiere (nessuna mancanza di rispetto), il team di gestione lo crederà e le attività saranno pianificate di conseguenza.

La cascata è fuori di favore ed è considerata la metodologia degli ultimi secoli, tuttavia non c'è nulla di sbagliato in questo, se è quello che stai cercando di ottenere, e in alcune situazioni il TDD combinato con Waterfall potrebbe essere un approccio preferibile (sto pensando outsourcing per sudare negozi dove il lavoro va al miglior offerente ....).

Sviluppare iniziando con i test è un ottimo approccio, tuttavia, richiedendo il completamento dei test prima che l'avvio del codice sia in grado di riprodurre l'intera classe di problemi creati da Waterfall e "design prima del codice", e questi sono facilmente evitati.

Suggerirei di guardare ad un approccio più flessibile, ad esempio "I test dovrebbero essere prima esaminati al 30% del tempo assegnato all'attività e alla revisione finale all'80%". Ciò consente al codice e ai test di evolvere insieme, ma stabilisce chiaramente le aspettative che i test siano almeno altrettanto importanti del codice.

L'accettazione finale richiede quindi che sia il codice che i test siano completi e rivisti.

Ti suggerisco caldamente di NON seguire questo approccio.

Scrivere test di unità in cima al codice di produzione è un sacco di spese generali per molte persone. Non importa come lo si affetta, con i test unitari, si finisce per scrivere il doppio se non il triplo della quantità di codice che avresti avuto altrimenti.

I test unitari sono ottimi e hanno un enorme numero di benefici, ma molti di questi benefici sono a lungo termine e non iniziano a pagare indietro più tardi (quando le persone devono fare riferimento su come utilizzare l'API, quando il prossimo -op rompe il codice esistente ... ecc.)

Tuttavia, i test unitari hanno enormi benefici a breve termine in quanto, quando le persone scrivono codice (con o senza TDD), le persone devono esercitare quel codice almeno una volta prima di verificarlo. In ambiente non TDD, proverebbero a esegui il codice nel contesto di un'applicazione più grande, oppure potrebbero scrivere alcune utilità throw-away solo per invocare le funzioni che hanno appena scritto. I test unitari sono fantastici perché mentre li stai scrivendo, puoi vedere il tuo codice correre e sistemarlo sul posto.

Quando una persona entra nel flusso (ciò che viene indicato come rosso / verde / refactor ciclo), overhead TDD, IMO basato su un'esperienza molto limitata (ma molta ricerca) diventa molto più piccolo di 2x perché anche se produci più codice, quel codice ti aiuta istantaneamente a scrivere il tuo software di produzione molto più velocemente fornendo feedback di un ordine di grandezza prima rispetto ai test manuali.

Quindi, idealmente, per ottenere il vantaggio con TDD con un minimo ammontare di spese generali, vuoi pensare alla prossima funzione che vuoi aggiungere alla produzione, scrivere un test, scrivere la funzione, assicurarti che passi, ripulire, andare avanti prossima funzione .... spediscilo.

Quello che stai proponendo ucciderà direttamente il beneficio a breve termine che ho appena descritto. Invece di scrivere un test e poi la funzionalità, finirai per scrivere molti test e il feedback sarà molto più lento poiché tra recensioni / approvazioni potrebbe richiedere ore se non giorni. E invece di scrivere il test esattamente per il prossimo pezzo di codice di produzione su cui lavorerai, finirai per scrivere test preventivi per cose che "potresti" introdurre in produzione.

Il ciclo TDD si basa sul feedback rapido: le revisioni asincrone post-commit infrangeranno il tuo ritmo.

Se vuoi che i test unitari siano approvati da un altro sviluppatore, la programmazione coppie è IMO un'idea molto migliore.

Personalmente, avrei paura di scrivere prima i test. La domanda è, cosa succede se i test sono passati?

Diciamo che ho speso un sacco di sforzi per scrivere buoni codici di test.

Dopo aver completato il codice principale, è molto difficile resistere a provare immediatamente questi test.

Ora cosa succede se i test sono passati? Significa che il mio codice è corretto a mia conoscenza migliore? Probabilmente no, ma probabilmente prenderò il passaggio dei test come scusa per concludere l'operazione.

Se non ho i test in anticipo, spenderò un sacco di sforzi per rivedere il codice per "dimostrare" che è corretto.

Quando un problema è abbastanza complicato, il potere del cervello è teso e calante nel tempo; Preferirei prenotare il tempo precedente per ragionare sui problemi principali.

Questa idea non sembra affatto praticabile. Sembra che si spenda più attenzione sulla verifica dei test rispetto al codice reale, il che non ha senso. I test possono passare, ma allo stesso tempo, il codice che sta testando può essere eseguito per 12 ore in produzione, il che rende la revisione del codice sui test inutile.

È anche il caso che il programmatore non sappia tutto sui requisiti del codice. È difficile scrivere test per qualcosa che non sei del tutto sicuro di come dovrebbe comportarsi, quindi i test "happy path" sono anche un po 'di fumo e specchi.

Aderisci di più a fail / pass / refactor invece - lascia che i tuoi sviluppatori scrivano piccoli morsi del codice, rivedi il codice della qualità del codice di calibro di produzione, poi lascia che continuino con i piccoli morsi di codice. Ti senti incoraggiato a rivedere i test per vedere se sono in realtà test , ma non lasciare che interrompa il flusso TDD.