Perché spesso si dice che i test case devono essere fatti prima di iniziare la codifica? [duplicare]

Scrivere test prima di implementarli è una delle idee chiave dietro Test Driven Development (TDD). La procedura è:

• scrivi un test fallito
• cambia il codice per farlo passare, senza interrompere nessun altro test
• ridefinisce il codice, verifica che tutti i test continuino a passare

Questa procedura è la stessa sia che si implementi una funzionalità o si risolva un bug; viene spesso chiamato "Red-Green-Refactor" (rosso = test fallisce, verde = test passa). I vantaggi di questo metodo sono numerosi:

• il test definisce chiaramente cosa costituisce "fatto"
• il test documenta come si intende utilizzare il codice
• se lo fai bene, costruisci una suite di test completa con una copertura del 100% come sottoprodotto del tuo processo di sviluppo, il che significa che hai sempre a portata di mano test di regressione affidabili, qualunque cosa tu faccia
La codifica
• per soddisfare un caso di test (e nient'altro) ti aiuta a concentrarti su un compito e previene il creep della funzionalità
• il ciclo red-green-refactor crea una cronologia di commit piacevole, pulita e tracciabile e si adatta bene ad un repository di feature branch (ogni branch di funzionalità inizia con un commit che aggiunge un test fallito, quindi uno o più commit fino a "green" "viene raggiunto e quindi uno o più refactoring si impegna).
• produci versioni di lavoro a intervalli regolari - idealmente, ogni ciclo di refettamento rosso-verde termina con un prodotto potenzialmente spedibile, ma per lo meno dovrebbe creare senza errori e superare tutti i test.

Ora per gli aspetti negativi:

• Non tutto il codice si presta a test automatizzati. Questo può essere perché è una base di codice legacy scritta senza test automatici in mente; può essere perché il dominio del problema è tale che certe cose non possono essere derise; o forse ti affidi a fonti di dati esterne che non sono sotto il tuo controllo e sarebbero troppo complicate da prendere in giro; ecc.
• A volte, correttezza, manutenibilità e stabilità non sono abbastanza elevate nell'elenco delle priorità. Questo suona male, ma non deve essere così: se stai scrivendo uno script monouso per convertire in batch una serie di documenti, scrivere test è sciocco - basta eseguirlo su alcuni documenti di test risultato, e questo è quello. I test automatici non aggiungerebbero alcun valore qui.
• Scrivere il test prima di scrivere il codice implica che sai già esattamente cosa vuoi fare. Molto spesso, però, non lo fai, e una quantità significativa di programmazione esplorativa è necessaria per avere un'idea del particolare dominio del problema; e il più delle volte, i risultati di tale codifica esplorativa vengono quindi messi a punto per diventare il vero prodotto. I test automatizzati sono altrettanto preziosi per questi prodotti, ma non ha molto senso aggiungerli prima di sapere cosa intendi fare. In questo caso, è meglio prendere il prototipo alla fine della fase esplorativa, aggiungere test per coprire tutto ciò che hai finora e passare da un referee rosso-verde da lì.
• Test-before-implementation non è la tazza di tè di tutti; scrivere l'implementazione prima sembra più naturale, e alcune persone hanno un tempo più facile entrare in un flusso in questo modo

Why is it often said that the test cases need to be made before we start coding?

È un principio di base dello sviluppo basato sui test , ma non di una "best practice" generale. Non tutti vogliono o hanno bisogno di fare TDD, anche se i suoi sostenitori affermano spesso che tutti ne trarrebbero beneficio.

What are its pros and what the cons if we don't listen to this advice?

Il vantaggio è che ti costringe a pensare al tuo codice da una prospettiva di test prima di scriverlo, il che ha due vantaggi principali: è meno probabile che tu dimentichi casi speciali e condizioni limite e il tuo codice deve essere testabile e quindi modulare Un altro importante vantaggio: in qualsiasi momento sai che il tuo codice funziona come pensavi che dovrebbe.

Lo svantaggio è che può incoraggiare a pensare a dettagli di basso livello ea trascurare importanti problemi di progettazione (ma lo stesso può accadere se si inizia a scrivere codice). Inoltre, il design più facilmente verificabile non è necessariamente il migliore (ma probabilmente molto meglio di uno sviluppato a partire dalla codifica ad hoc).

Ovviamente c'è la domanda se TDD risparmia più tempo rispetto alla scrittura di tutti quei costi dei test unitari. I suoi sostenitori certamente lo affermano.

Moreover, does that advice refer to black box testing or White Box testing or both?

Di solito, TDD si occupa esclusivamente di test di unità , che sono test di riquadri bianchi. Test di integrazione devono essere fatti in aggiunta.

Quando scrivo per primo test , non è tanto una questione di verificare il corretto funzionamento del mio codice, non è veramente una questione di scatola nera o scatola bianca o qualsiasi altra cosa relativa a garanzia della qualità , ed ecco perché ...

Nel corso degli anni ho esercitato e lucidato un'abilità per convincere il management che ho bisogno di buoni tester ^{1 , 2 , 3} e questo è sufficiente per garantire che il mio codice funzioni come previsto senza che io debba pensarci molto.

Il motivo principale per cui preferisco testare per primo è che mi aiuta a capire come progettare il mio codice in modo che sia comodo da usare. Non sono bravo a immaginare nella mia testa come il mio modulo sarà usato da altri moduli, quindi posso farlo troppo complicato e questo mi morderà più tardi e forse richiederà anche una riprogettazione.

Questo è un problema, non importa se sto codificando un modulo per me o per qualcun altro, è ugualmente doloroso usare me stesso un'interfaccia scomoda e dover spiegare il suo utilizzo ad altri programmatori.

L'approccio "primo test" mi salva da quel dolore; non richiede immaginazione per vedere immediatamente come verrà utilizzato il mio modulo se progettato in questo modo e semplifica la scelta di quello più conveniente.

Quando codifica il modulo per qualcun altro, mi salva anche dalla necessità di spiegare dolorosamente come usarlo.

^{Look, code in this test shows how you should use that module and if you run it, you'll also see what results you should expect. Using any other way than shown in this test would be a mistake. Now go away and let me do something interesting.}

Si dice nel contesto della pratica di TDD / BDD , che sono metodologie design , non metodologie di test.

Con TDD / BDD, l'idea è di eliminare l'utilizzo dell'API prima di scrivere l'API, evolvendola con i test.

Visto in questa luce, il punto è scrivere un test per una chiamata API non esistente o un test per un comportamento API non esistente e quindi implementarlo.

Come per i test blackbox / whitebox - ancora, non si tratta di testing - si tratta di design .

Why is it often said that the test cases need to be made before we start coding?

Ci sono un paio di motivi per cui questo è stato detto.

• Alcune persone si avvicinano ai test (blackbox) come contratti. Ciò costringe la persona che scrive il test e la persona che implementa il codice a disporre di un chiaro insieme di criteri per il successo. Ciò significa che si scrive codice per soddisfare il contratto ed è così che si sa quando viene soddisfatta la funzionalità richiesta.
• TDD (Test Driven Development) è una pratica in cui si guida tutto lo sviluppo attraverso i test. Classicamente questo viene fatto con i test unitari, ma più recentemente con i test a qualsiasi livello sono appropriati per il tuo prodotto e processo.

What are its pros and what the cons if we don't listen to this advice?

Pro

• Elimina le ambiguità precedenti nel processo perché devi capire quali sono i criteri di successo prima di scrivere il test.
• Alcuni sostenitori suggeriscono che vi siano vantaggi di progettazione specifici per l'unità TDD perché impone un accoppiamento libero e una progettazione più modulare.
• Fiducia che il tuo codice funzioni (almeno per le parti testate).

Contro

• Scopri come scrivere test mantenibili.
• Scopri come scrivere buoni test.
• Comprendi quando effettuare il trade off tra un buon test molto costoso e un test meno buono a basso costo.
• Altro codice da mantenere

Moreover, does that advice refer to black box testing or White Box testing or both?

Dipende. La maggior parte dei test unitari tendono ad essere più blackbox in quanto esamineranno input e output del metodo o della funzione. Tuttavia, ci sono momenti in cui sono necessari mock o stub che lo rendono più di un test whitebox in quanto richiede informazioni sull'implementazione. Potrebbe essere un punto controverso ai fini del TDD perché lo sviluppatore è in genere quello che scrive i test.