Come testare il viaggio del cliente con la maggior parte della stessa struttura

Question

Come testare il viaggio del cliente con la maggior parte della stessa struttura

#1 da (0 voti)

1

Spesso sento che un test dovrebbe contenere solo un'asserzione (trascurando gli attributi di test di una classe) e dove tutte le pre-condizioni per il test dovrebbero essere impostate prima dell'asserzione.

Nella nostra applicazione abbiamo molti test in cui un utente dell'applicazione accede, esegue alcune azioni, quindi lo stato dell'applicazione è asserito, quindi l'utente fa un'altra cosa ecc. e un'altra asserzione viene convalidata. Un altro test potrebbe quindi differire solo in alcune azioni intraprese durante il test. Ad esempio (Pseudo codice)

Test 1:
user = new User()
assertThat(user).is(created)
products = user.buyProducts(2 items)
assertThat(product.length, is(2))


Test 2:
user = new User()
assertThat(user).is(created)
product = user.buyProduct()
assertThat(product, is(notNullValue()))

Questo porta a test che a volte sono estremamente lunghi (a volte 50-100 linee, senza contare i metodi di supporto) e spesso differiscono solo in una delle nostre due dichiarazioni. Sfortunatamente, le diverse dichiarazioni spesso non sono solo sostituzioni variabili, quindi non possiamo usare test dinamici come con Junit5.

C'è un altro modo migliore per creare i test? Sfortunatamente la maggior parte dei test delle nostre applicazioni sono configurati in questo modo. Penso inoltre che potrebbe essere troppo sintetico per mettere tutte queste configurazioni in diversi metodi di configurazione e creare classi di test che fondamentalmente si fermano nel mezzo (ad esempio dopo aver affermato che l'utente è stato creato), e quindi creare un'altra classe di test che afferma solo che il prodotto è stato acquistato.

testing java

posta Hellstorm 04.09.2018 - 14:32

fonte

1 risposta

Leggi altre domande sui tag testing java

Come rappresentare un tipo specifico di dipendenza dell'interfaccia nel diagramma dei componenti? Identifica metodi specifici e i loro parametri nel codice sorgente

score 0 · Answer 1

La massima che un test dovrebbe avere una sola asserzione è volta a facilitare il debugging. Se un test con più asserzioni fallisce, non è sempre immediatamente evidente quale asserzione abbia avuto esito negativo. In altre parole, la regola ha lo scopo di farti risparmiare tempo nel debugging.

Detto questo, i test richiedono tempo per essere eseguiti. E, se li stai eseguendo regolarmente, come dovresti essere, allora quel tempo si mescola. Pertanto, se si dispone di una suite di test che richiede parecchio tempo di configurazione, potrebbe valere la pena combinare più asserzioni in un singolo test per evitare di ripetere l'installazione.

È un compromesso. O impieghi un po 'più di tempo per eseguire il debug o trascorri un po' più di tempo in attesa dell'esecuzione dei test.

In generale, trovo che i test unitari siano meglio conservati in una singola asserzione. Questi test sono generalmente di piccole dimensioni, con impostazioni minime / veloci. Pertanto, ha senso ottimizzare per il debugging più veloce, poiché i test sono già veloci.

D'altra parte, trovo che i test di funzione siano meno adatti alla singola asserzione per regola di test, poiché in genere questi test richiedono un'impostazione più / più lenta. In altre parole, va bene mettere insieme le asserzioni in modo da ottimizzare l'esecuzione del test più veloce.

Per l'esempio specifico presentato sopra, se creato un User è un'operazione poco costosa, vorrei andare con una asserzione per test:

Test 1:
user = new User()
assertThat(user).is(created)

Test 2:
user = new User()
products = user.buyProducts(2 items)
assertThat(product.length, is(2))

Test 3:
user = new User()
product = user.buyProduct()
assertThat(product, is(notNullValue()))

Altrimenti, se la creazione di User è un'operazione costosa e dispendiosa in termini di tempo, combinerei più asserzioni in un test:

Test 1:
user = new User()
assertThat(user).is(created)
product = user.buyProduct()
assertThat(product, is(notNullValue()))
products = user.buyProducts(2 items)
assertThat(product.length, is(2))

Il classico esempio di questo è testare un'applicazione che richiede all'utente di accedere prima di eseguire qualsiasi azione. Crei cinque diversi test, ognuno dei quali deve accedere prima all'utente? Oppure, crei in prova con cinque asserzioni?

È un compromesso.