Confusione tra test E2E, test delle unità e dati di simulazione con $ httpBackend

Question

Abbiamo appena iniziato a sviluppare un'app Web con AngularJS e stiamo riscontrando alcuni problemi con il test corretto in modo da poter dare un consiglio.

In generale, ci sono i seguenti componenti da testare:

1. Web API
2. Controller angolari
3. angolare di routing
4. rendering HTML e angolare vincolante dei controllori agli elementi HTML

Come si può testare tutto questo con il minimo sforzo e, se possibile, non sovrapporre?

Per qualsiasi applicazione basata su database, il test di integrazione completo (ad esempio con un server attivo, connesso a un database caricato con dati) sarebbe particolarmente disordinato perché ci dovrebbe essere un processo che genera dati sufficienti per tutti i test e ripristini il DB e i test dovrebbero fare attenzione a non modificare i reciproci dati. (se mi manca qualcosa qui per favore fatemelo sapere)

Dato il punto precedente, suppongo che sia meglio interrompere il collegamento tra server e client ed eseguire i test angolari usando solo dati fittizi.

Inoltre, presumo che se il test E2E si prende cura di tutti gli scenari possibili, i controllori dell'unità di test sono ridondanti in quanto i loro valori sono legati al modello (e quindi verrebbero testati tutti i 2, 3 e 4 sopra). Il test delle unità sarebbe utile solo in controllori molto complessi o per testare servizi e direttive.

Tuttavia, non siamo riusciti a trovare alcuna informazione su come prendere in giro roba con $httpBackend su una base per test come si farebbe nei test unitari, usando expect*(). I documenti angolari sembrano suggerire l'uso di when*() più gli occasionali passthrough() quando necessario.

Tuttavia, questo pone il suddetto problema di creare dati di test per tutti gli scenari e probabilmente sarà necessario reimpostare il DB in memoria prima di ogni test per assicurarsi che i test non siano interessati. Inoltre, stai perdendo la sicurezza dell'uso di $httpBackEnd.expect*() che controlla che non vi siano chiamate mancanti o ridondanti al server - Questo mi suggerirebbe di richiedere anche che i controllori dell'unità di test controllassero ciò.

Qualcuno può fornire una strategia di test dettagliata per le app AngularJS che risolve il test dei 4 componenti sopra e le preoccupazioni riportate sopra?

Answer 1

1. Non sono sicuro - dal momento che la vostra applicazione angolare è teoricamente disaccoppiato dal terminale, non c'è alcuna ragione particolare che i test angolari e test di back-end devono essere commingled. Li testerei separatamente, con ogni suite di test assumendo che l'altro componente funzioni correttamente. Quindi, quando si esegue il test angolare, si presuppone che il server funzionerà come previsto.

2. Test di unità: forniscono maggiore profondità rispetto ai test E2E. È più semplice verificare le condizioni specifiche che il codice dovrà affrontare. È anche facile prendere in giro tutte le dipendenze, se necessario, e testare solo il componente a cui sono interessati i test unitari. I test unitari non riguardano il modo in cui funziona l'interfaccia utente o il corretto collegamento dei dati, ma piuttosto la logica aziendale dell'app è corretta.

3. (e 4) test E2E - meno granularità, concentrandosi su come assicurarsi che l'interfaccia utente sia come previsto dal punto di vista dell'utente finale. Hai ragione che è complicato testare un database live (anche se alcune persone godono della sicurezza offerta da un test di integrazione end-to-end completo), e quindi dovresti usare $httpBackend per deridere il server.

Answer 2

Consultare questo https://www.sitepoint.com/unit-and-e2e-testing-in-angularjs/. Se il servizio/fabbrica utilizza il servizio http per chiamare un'API remota, è possibile restituire dati falsi da esso per il test dell'unità. Se si sta avviando un nuovo progetto Angolare, prendere in considerazione l'utilizzo di Goniometro per i test E2E.