Strategie di esecuzione del test di accettazione per app pesanti per la prima installazione

5

Abbiamo un sistema con circa 250 tabelle. La prima installazione include circa 50 query (conosciute anche come seed).

Stiamo provando le strategie per automatizzare i nostri test di accettazione e la nostra prima scelta è stata pulire e ricostruire il database su ogni scenario (ovvero: ogni test), in modo da poterli tenere isolati dagli altri: cioè un " elenco di tutte le risorse "lo scenario non controllerebbe la presenza di una risorsa creata in uno scenario" creato "precedentemente eseguito.

Non sono sicuro, se questo "isolamento" porterà vantaggi quantificabili, ma renderà ogni tempo di esecuzione di ogni scenario più lungo (circa 20 secondi ogni scenario).

È considerato una cattiva pratica, o porterà qualsiasi problema di scalabilità noto, se cambiamo la nostra strategia per fare questa prima installazione solo all'inizio della configurazione fase dell'esecuzione dei test (o forse all'inizio di ciascuna suite di test) piuttosto che su ogni scenario?

Se è utile, stiamo testando utilizzando Behat (la versione ufficiale di PHP di Cucumber ).

    
posta Christopher Francisco 13.11.2016 - 23:44
fonte

1 risposta

2

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?

  1. Puoi cambiare il modo in cui scrivi il nuovo test in modo che non cambi lo stato per i test conseguenti
  2. 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!

    
risposta data 14.11.2016 - 02:58
fonte

Leggi altre domande sui tag