Test end-to-end vs. test unitari, i test dovrebbero essere disaccoppiati?

Nella nostra azienda in genere ci assicuriamo di scrivere un test end-to-end per i nostri siti Web / app Web. Ciò significa che accediamo a un URL, compiliamo un modulo, inviamo il modulo a un altro URL e controlliamo i risultati della pagina. Facciamo questo per testare la validazione dei moduli, verificare che i modelli HTML abbiano le variabili di contesto corrette, ecc.

Lo usiamo anche per testare indirettamente la logica sottostante.

Mi è stato detto da un collega che la ragione di ciò è che possiamo strappare e cambiare l'implementazione sottostante in qualsiasi momento finché i test end-to-end passano.

Mi chiedo se questo tipo di disaccoppiamento abbia senso o se sia solo un modo per evitare di scrivere test per unità di codice più piccole?

Sono inoltre necessari test end-to-end. In quale altro modo puoi sapere di aver collegato correttamente tutte le unità? Su un codice molto semplice, è possibile testare tutti i percorsi attraverso il codice solo con test end-to-end, ma man mano che si ottengono più livelli, diventa proibitivamente 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 ciascuna unità con solo 5 · 3 test unitari. Se esegui 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 anche i test unitari. Idealmente, li avete entrambi, poiché entrambi in genere catturano diversi tipi di bug. Pertanto, avere test end-to-end non dovrebbe mai essere una scusa per non avere test unitari.

Dopo qualche altro anno di programmazione e di elaborazione di progetti, fornirò una risposta alla mia domanda.

Sì, dovresti scrivere unit test. I test end-to-end sono più difficili da scrivere e fragili soprattutto se si basano su componenti dell'interfaccia utente.

Se si utilizza un framework come Django o Rails (o le proprie classi personalizzate), è necessario disporre di una classe di modulo che gestirà la convalida del modulo. Avrai anche classi di visualizzazione che visualizzano modelli renderizzati e il modulo e gestiscono le richieste GET e POST.

In un test end to end dovresti:

1. ottenere l'URL
2. compila il modulo con dati validi
3. invia il modulo all'URL
4. verificare 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à piuttosto buona, ma stai solo testando il percorso felice quando tutto va bene. Come assicurate che il modulo abbia la giusta validazione in esso? Cosa succede se quel modulo viene utilizzato su più pagine? Scrivi ancora un altro test end-to-end?

Riproviamo con i test unitari:

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

Usando unit test, stai testando piccoli pezzi di codice e i test sono specifici e più facili da scrivere. Combinando questo con TDD (Test Driven Development) si ottiene un codice di qualità superiore.

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

In realtà test end-to-end o test di integrazione sono più importanti dei test unitari poiché assicurano che tu abbia un sistema completamente funzionante. I test unitari non coprono la parte di integrazione di un sistema, il che è un compito complicato soprattutto nei grandi progetti.

Tuttavia, come è stato detto, è necessario eseguire anche test unitari, poiché è più complicato individuare i casi limite nei test di integrazione.

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

Nel mio lavoro facciamo lo sviluppo guidato dai test di accettazione senza test unitari che sembrano simili a quelli che hai descritto. Abbiamo iniziato a fare entrambe le cose e, nel tempo, alla fine abbiamo eliminato i test unitari a un costo superiore ai benefici per noi.

Detto questo, penso che il costo / beneficio per il tuo dominio e ambiente problematico dovrebbe guidare le decisioni a impegnarsi in qualsiasi pratica di sviluppo, incluse diverse pratiche di test automatizzati. Piuttosto che la fede, preferisco che tutte le pratiche abbiano prove empiriche nel contesto in cui vengono utilizzate per sostenerle.