Il test end 2 end è sufficiente?

Question

Le mie domande riguardano principalmente la metodologia di test. Sto lavorando per un'organizzazione che pratica TDD (Test Driven Development). Stiamo utilizzando AngularJS e quindi il suo stack completo di test: Jasmine per i test unitari e il goniometro per i test e2e.

Durante lo sviluppo di una funzione, il nostro processo inizia scrivendo prima un test e2e non funzionante e poi scrivendo la funzione che utilizza TDD. I test sono scritti solo per metodi pubblici (sia per controller/direttive/servizi). Il prodotto in sé non contiene alcuna logica complessa (a parte un paio di eccezioni). Recentemente abbiamo iniziato a discutere del fatto che non c'è motivo di scrivere i test unitari per i controllori, poiché stanno esponendo le funzionalità, il 100% di essi è esposto alla vista e comunque testato con i test e2e. Fondamentalmente - test di unità e test di e2e si sovrappongono. All'inizio eravamo tutti d'accordo, ma poi questa decisione ha aperto una scatola di Pandora. Dopotutto, si potrebbe dire la stessa cosa delle direttive. Quindi, perché testarli anche loro? Poi è arrivata la domanda di servizi. La maggior parte di loro (98%) effettua semplicemente una chiamata di back-end e restituisce la risposta. Quindi, perché non prendere in giro semplicemente httpBackend e testare i servizi durante il test dei controller, che vengono testati tramite e2e.

si ottiene la deriva ....

Vedo beneficio nel fare entrambe le unit test e test E2E, loro malgrado praticamente sovrapposte. Principalmente - feedback immediato e "documentazione eseguibile". Cosa stai praticando? Vedi altri vantaggi ed è "succo che vale la pena" - vale la pena scrivere test di sovrapposizione per le implementazioni più semplici solo per ottenere questi due vantaggi sopra?

Answer 1

Questo è un grande argomento e non qualcosa che può davvero avere una risposta autorevole, ma farò del mio meglio per coprire alcuni punti.

In primo luogo, si dovrebbe pensare allo scopo dei test. Secondo lo Agile Testing Quadrants, i test unitari esistono principalmente per supportare il team. Generalmente sono scritte vicino al prodotto (ad esempio usando TDD, probabilmente dagli stessi sviluppatori) e servono ad aumentare la fiducia dello sviluppatore che non hanno rotto niente con quell'ultima modifica. Con questa sicurezza, gli sviluppatori possono lavorare in modo efficiente e rifattore con abkon spericolato - il sogno TDD. I test unitari non rispondono alla domanda "È adatto allo scopo del nostro cliente", ma non è questo il motivo per cui sono lì.

Test funzionali (e2e, se ho compreso la descrizione) supporta ancora la squadra con una rapida rotazione dei risultati del test, ma in realtà inizia a rispondere alla domanda "Un utente può fare la cosa?". Stai testando ciò che l'utente vede e iniziando a testare il tuo prodotto reale in modo significativo per gli utenti.

quadranti 3 e 4 inizio per affrontare il se il prodotto fa la cosa ben (es. È adatto allo scopo e non solo funzionale), ma questo è un altro argomento.

Sulla base di questa comprensione dei test, parte della risposta dipende dalla struttura del team. Hai un team di sviluppo e test separato? In tal caso, potrebbe essere logico che i tuoi sviluppatori scrivano test di unità (dopotutto sono a loro vantaggio) e che il team di test possa gestire gli altri quadranti in modo indipendente (inclusa la scrittura di e2e come meglio ritengono). E se la tua squadra di test e dev è la stessa? Se è possibile ottenere un tempo di consegna simile (test scritto -> risultato utile) dai test funzionali/e2e possibile dai test unitari, può essere opportuno concentrarsi su di essi e raccogliere i frutti per entrambi i metodi senza sovrapposizione.

La risposta breve che vorrei dare è semplicemente chiedere "Quali benefici stiamo ottenendo da questo test?".Se trovi le risposte per i test che si sovrappongono, potrebbe essere sensato rimuovere la ridondanza.

Alcuni dei suddetti punti e alcuni altri sono discussi here, quindi per ora smetterò di vagare.