"Iterazione zero": test di accettazione end-to-end in modalità di contatto semplice

Question

Stavo leggendo "Software orientato agli oggetti in crescita, guidato dai test" ultimamente. Gli autori di questo libro hanno suggerito di iniziare sempre a sviluppare una funzionalità con un test di accettazione end-to-end (prima del avvio del ciclo TDD) per non perdere una traccia di avanzamento e assicurarsi di essere ancora sulla stessa pagina unit test.

Ok, quindi ho iniziato a scrivere una semplice applicazione veeeery in python + django solo per provare questo approccio. Voglio che l'utente sia in grado di fare una domanda tramite il modulo di contatto, la domanda dovrebbe essere quindi memorizzata in un db, e un segnale dopo il completamento dovrebbe essere inviato per notificare il mittente che invierà un messaggio di follow-up.

La domanda è: come ci si avvicina a questo primo test end-to-end in questo caso? Hai contenuto tutte le possibilità in questo primo test, o forse sto fraintendendo questa intera tecnica.

Qualsiasi esempio sarebbe il benvenuto.

Answer 1

Non è necessario che contenga tutte le possibilità nei test di accettazione - continuerai a scrivere test di unità. Quindi direi che un singolo test "l'utente può compilare il modulo, salvarlo e ricaricarlo" è sufficiente per iniziare. Quindi puoi aggiungere altri test se pensi che un particolare aspetto del tuo sistema sia abbastanza importante da richiedere un test di accettazione. Non preoccuparti di gestire tutte le possibilità qui, scriverai ancora tonnellate di unit test dove testerai tutto!

Il modo più semplice per iniziare è far crescere il test di accettazione in parallelo con il codice: inizia quindi con il test che l'utente può immettere dati, implementarlo finché non si interrompe, quindi aggiungere al test la condizione che l'utente ha per caricare questi dati indietro ecc. Ci vorrà un po 'di tempo per implementare l'infrastruttura iniziale per il test di accettazione, prima ancora di iniziare a scrivere il codice di produzione, ma non è possibile uscirne comunque, e ci sono vari vantaggi per avere i test in anticipo.

Answer 2

Questo caso d'uso porta a diversi casi di test (ogni test rappresenta un possibile percorso di esecuzione dedicato).

Quando i test di scrittura si concentrano su un possibile risultato, dopo un po 'la suite di test cresce. I primi test forniscono anche la rete di sicurezza come test di regressione per non rompere nulla che hai già implementato con successo.

miei primi test sarebbero:

• percorso Felice frontend-forma 1 ° parte + strato di controllo: l'utente passa dati corretti, il regolatore prendono la forma e log di consolare/stdout
• percorso Felice 2a parte: Anziché accedere allo stdout, le cose vengono archiviate nel database
• Percorso felice Terza parte: la posta di follow-up viene inviata e ricevuta dall'utente
• Gestione errore convalida (i riempimenti utente si formano in modo errato, ad esempio mancano campi obbligatori, e-mail errate modello)
• ...

compilare il resto;) dipende dai requisiti più dettagliati ...

Ricordati di implementare sopra il più semplice possibile. Quando tutti i test sono a posto, refactoring spietatamente per rendere la "qualità interna" piacevole.