Questa non è affatto una cattiva pratica. Può sembrare eccessivo, ma fare integrazione / tipo di test del sistema in questo modo ti dà enormi benefici.
I Test diventano molto meno fragili quando li imposti in questo modo. Immagina di aggiungere un nuovo test solo per scoprire che tutti gli altri test eseguiti successivamente non riescono. Questo accade perché questi altri test dipendono da uno stato precedente che ora hai modificato. Cosa fai adesso?
- Puoi cambiare il modo in cui scrivi il nuovo test in modo che non cambi lo stato per i test conseguenti
- Si aggiornano tutti gli altri test dietro a quello nuovo
Entrambe le opzioni sono piuttosto terribili. L'opzione # 1 ti costringe troppo così invece di scrivere un test che verifichi completamente il caso d'uso, scrivi un test in cui testare solo una funzionalità. L'opzione n. 2 richiederà un'eternità e ti lascerà con un sapore aspro in bocca.
Se applichi la strategia in cui i test non dipendono dallo stato precedente, devi solo eseguire quel singolo test conoscendo con un'alta probabilità che funzionerà correttamente come parte dell'intera suite. Di conseguenza, richiede molto meno tempo dallo sviluppo a piena integrazione . La possibilità di eseguire un singolo test da sola rende molto più facile isolare ed eseguire il debug dei problemi . Il contesto che uno sviluppatore deve tenere nel proprio cervello è anche minimizzato in questo modo, rendendo più facile concentrarsi sul compito da svolgere. Per riassumere ci vorrà molto meno tempo e anche molto più divertente per sviluppare e mantenere tali test.
Come hai menzionato, un negativo per impostare lo stato prima di ogni test è che l'esecuzione complessiva della suite richiede più tempo. Sono d'accordo che questo è fastidioso e devi considerare quanto spesso questi test devono essere eseguiti. Nelle mie squadre, il tipo di test di accettazione ha funzionato al massimo una volta al giorno, ma non tutti gli assegni e avevano una propria build dedicata (in altre parole, erano NON parte di integrazione continua ).
Un modo per accelerare il tempo di esecuzione dei test è limitare la quantità di seeding per i singoli test. Considera solo la semina del minimo assoluto richiesto dal caso di test specifico.
Devi anche rendere facile e diretto il seeding iniziale. La manutenzione degli script seme è una parte importante del mantenimento dei test stessi . Devi essere in grado di condividere facilmente l'intestino del seeding tra i test (pensa ai metodi / classi di semi che riusare nella configurazione) che rende più facile per tutti i seed e renderli centralizzati, quindi se qualcosa cambia fondamentalmente hai solo bisogno di aggiornamento in un posto.
Spero che questo aiuti. Buona fortuna e prova!