L'obiettivo ideale per il mio sistema è la possibilità di eseguire un numero arbitrario di distribuzioni al giorno per la produzione, assicurandoci che ogni 'push' passi attraverso l'intera suite di test per assicurarsi che tenga conto delle nostre specifiche / storie utente.
Questa è una sfida gestibile con i test di integrazione / unità che di solito sono solidi, ma non è ragionevole quando provo a testare i test E2E che sono notoriamente flakey (ea volte falliscono a causa di circostanze sconosciute).
Uso spesso i test E2E per testare le storie complete degli utenti utilizzando NightwatchJS . Un tipico test può iniziare da un login e consiste in una sequenza di passaggi complicati che vengono eseguiti in ordine. Faccio del mio meglio per assicurarmi che tutti i test E2E siano il più piccoli possibile (quindi quando falliscono altre storie utente non vengono saltati) ma sono ancora soggetto a errori di test spesso casuali che fanno sì che eseguirli come parte della pipeline di implementazione no- partire.
Ho quindi alcune domande su come le altre organizzazioni che ricevono più distribuzioni al giorno gestiscono i test nella loro pipeline di distribuzione:
- Quale tasso di errore trovi per la tua suite di test E2E? Come lavori come squadra per migliorarlo
- A quale fase della distribuzione vengono eseguiti i test E2E: automaticamente prima dell'unione con il master? Manualmente? Una piccola modifica del back-end determina l'esecuzione di una suite E2E? Quanto tempo prolunga la tua pipeline di implementazione?
- Un errore del test E2E è uguale a un errore di distribuzione?
- In quale ambiente vengono eseguiti i test E2E, su macchine di sviluppo locale? nei server QA? su ambienti di sviluppo condivisi? su Staging?
Sono davvero interessato a scoprire a che punto si dirigono le suite di test E2E e quali livelli di sfarfallio provate. Qualsiasi input sarebbe fantastico!
Saluti Deepak