Test end-to-end rispetto ai test unitari, i test dovrebbero essere disaccoppiati?

Sono anche necessari test end-to-end. In quale altro modo puoi sapere che hai collegato tutte le unità correttamente? Su un codice molto semplice, è possibile testare tutti i percorsi attraverso il codice con solo test end-to-end, ma man mano che si ottengono più livelli, diventa decisamente più costoso farlo.

Ad esempio, supponiamo di avere tre livelli, ciascuno con cinque possibili percorsi. Per testare tutti i percorsi attraverso l'intera applicazione richiederebbero 5 ³ test end-to-end, ma è possibile testare tutti i percorsi attraverso ogni unità con solo 5 · 3 unit test. Se si eseguono solo test end-to-end, molti percorsi finiscono per essere trascurati, principalmente nella gestione degli errori e nelle condizioni al contorno.

Sì, i test end-to-end (o test di integrazione) hanno molto senso, ma lo sono anche i test unitari. Idealmente, avete entrambi, dal momento che entrambi tipicamente catturano diversi tipi di bug. Quindi, avere test end-to-end non dovrebbe mai essere una scusa per non avere test unitari.

In realtà i test end-to-end oi test di integrazione sono più importanti dei test unitari poiché assicurano un sistema pienamente funzionante. I test unitari non coprono la parte di integrazione di un sistema, che è un compito complicato specialmente in progetti di grandi dimensioni.

Tuttavia, come è stato detto, dovresti fare anche il test delle unità, poiché è più complicato catturare i casi limite nei test di integrazione.

Dopo alcuni anni di programmazione e lavorazione dei progetti, fornirò una risposta alla mia domanda.

Sì, dovresti scrivere test unitari. I test end-to-end sono più difficili da scrivere e fragili, specialmente se si affidano a componenti dell'interfaccia utente.

Se utilizzi un framework come Django o Rails (o le tue classi personalizzate) dovresti avere una classe modulo che gestirà la convalida del modulo. Avrai anche le classi di visualizzazione che visualizzano i modelli di rendering e il modulo e gestiscono le richieste GET e POST.

Nel test end-to-end ti piacerebbe:

1. ottieni l'URL
2. compila il modulo con dati validi
3. pubblica il modulo nell'URL
4. controlla per accertarti che il database sia stato aggiornato o che sia stata eseguita qualche azione come risultato del modulo valido

Stai testando un sacco di codice e la tua copertura sarà abbastanza buona, ma stai solo testando la strada felice quando tutto va bene. Come ti assicuri che il modulo abbia la giusta validazione in esso? Cosa succede se quel modulo è utilizzato su più pagine? Scrivi ancora un altro test end-to-end?

Proviamo di nuovo con i test unitari:

1. prova il metodo GET della vista
2. verifica il metodo di visualizzazione POST con un falso / modulo di simulazione
3. verifica il modulo con dati validi
4. verifica il modulo con dati non validi
5. verifica gli effetti collaterali del modulo

Usando i test unitari, stai testando pezzi di codice più piccoli ei test sono specifici e più facili da scrivere. Quando lo combini con TDD (Test Driven Development) ottieni un codice di qualità superiore.

La facilità di scrittura dei test unitari non deve essere ignorata perché quando sei su un progetto che ha nessun test automatico, devi iniziare da qualche parte. Iniziare con i test unitari è più facile e veloce e ti consente di iniziare immediatamente a testare i bug piuttosto che solo per il percorso felice.

Verifica il comportamento del sistema, mentre i test unitari verificano il comportamento dell'unità. I benefici e i costi per ciascuno sono diversi. Potresti fare l'uno o l'altro o entrambi.

Al mio lavoro eseguiamo lo sviluppo basato su test di accettazione senza test unitari che sembrano simili a quello che hai descritto. Abbiamo iniziato a fare entrambe le cose e nel tempo, alla fine abbiamo eliminato i test unitari al costo, superando i vantaggi per noi.

Detto questo, ritengo che il rapporto costi / benefici per il dominio e l'ambiente problematico debbano guidare le decisioni a impegnarsi in qualsiasi pratica di sviluppo, incluse diverse pratiche di test automatizzate. Piuttosto che la fede, preferisco che tutte le pratiche abbiano prove empiriche nel contesto del loro uso per sostenerle.