Come rilevare le modifiche dell'API quando si prendono in giro i test di e2e?

Question

mi piacerebbe impostare una fondazione test E2E solida su progetto del nostro team, ma non riesco a trovare una soluzione semplice a questa domanda:

Quando si sta prendendo in giro tutte le chiamate, qual è il modo migliore per rilevare se il modello effettivo degli oggetti restituiti dal server è stato modificato?

I test passeranno ancora perché stanno testando una versione obsoleta del modello ma l'app è potenzialmente danneggiata.

Ad esempio, se un finto presuppone che /api/users/1 restituisce null se l'utente non esiste, quando in realtà restituisce un oggetto vuoto, quindi anche se le prove possono passare, il comportamento in fase di test si basa su presupposti errati e possono pertanto sicuro in modi inaspettati.

O forse il backend in qualche modo fornisce file json statici con l'ultimo modello aggiornato e il frontend si basa su questo?

Questo naturalmente presuppone che le persone che lavorano sul back-end e le persone che lavorano sul front-end siano squadre separate.

Qui sto usando 1.x angolare e goniometro, ma questo non dipende realmente dalla tecnologia.

Answer 1

Penso che quello che stai facendo (isolamento frontend durante i test) sia corretto, mantienilo in questo modo.

Che cosa si può fare per verificare le prende in giro è una di quelle:

1) Se frontend e backend sono strettamente accoppiati e sviluppati insieme - aggiungere una serie di test di unità per il backend per verificare le risposte API. In questo modo se qualcosa cambia in API, i test di back-end falliranno e saprai che anche i frontend mock dovrebbero essere aggiornati.

Durante lo sviluppo è possibile eseguire entrambi i set di test (test di e2e e backend unit) periodicamente o anche su ogni cambio di codice.

2) Se il frontend è più o meno indipendente dal back-end, è necessario disporre di alcuni test di integrazione, che verranno eseguiti oltre ai test e2e. Questi dovrebbero eseguire le richieste HTTP effettive al back-end e confrontare la struttura dei dati restituiti con i vostri mock. In questo modo è possibile rilevare la situazione quando i mock diventano obsoleti.

Il secondo approccio è più affidabile, ma i test di integrazione saranno probabilmente più lenti dei test dell'unità di back-end, quindi è possibile eseguirli automaticamente solo sul server CI e non durante lo sviluppo locale.

Answer 2

È necessario registrare un http interceptor che memorizza i dati su richiesta: window.e2eHttp[request.url] = null;, la risposta + responseError: window.e2eHttp[request.url] = result;

È possibile utilizzare il sistema di moduli angolare del goniometro per iniettare o utilizzare una bandiera nella soluzione, e2eService.isEnabled(), per attivare o disattivare acceso e spento l'intercettore.

Quindi nel test e2e è necessario implementare un browser.wait + browser.executeScript fino a quando window.e2eHttp[request.url] dispone di dati. Avrà sempre un oggetto di risposta http angolare (intestazioni di stato http, dati, ect)

Answer 3

Una soluzione simile a @Lablanc Meneses risparmierebbe la risposta di ogni chiamata in un file JSON.Salvare la risposta all'interno dell'intercettatore per i test e2e, quindi utilizzare il file JSON salvato per i test e2e. Queste chiamate JSON verrebbero automaticamente aggiornate ogni volta che si esegue il servizio API. ciò richiederebbe l'esecuzione di tutti i servizi una volta per memorizzare il modello per la prima volta e quindi utilizzarlo per i test e2e. Il modello verrà aggiornato non appena verrà eseguita l'API aggiornata. puoi creare un interruttore per interrompere il salvataggio della risposta per la tua build di produzione.