Test di accettazione per modulo online multi-passo di grandi dimensioni

Question

Test di accettazione per modulo online multi-passo di grandi dimensioni

#1 da (5 voti)

4

Devo estendere / correggere un grande modulo online scritto da altri sviluppatori. C'è molto codice, mescolando PHP e JS. È una specie di stile di scrittura di sola scrittura e voglio rifare completamente, ma al momento non posso.

Funziona così:

È un modulo in stile wizard con 12 passaggi: chiamiamoli fasi per non confondere con passaggi dei test.
L'utente deve riempire almeno ~ 100 campi per finire.
Alcuni campi sono raggruppati per 3-5. Questi gruppi possono essere aggiunti e rimossi dinamicamente con JS.
La convalida viene eseguita dopo l'invio di ciascuna fase. Se si sono verificati degli errori, l'utente viene avvertito immediatamente e non può andare oltre finché non risolve tutti gli errori.
I dati inviati vengono temporaneamente memorizzati nella sessione tra le fasi. Nessuna archiviazione permanente.
L'utente non può saltare le fasi, solo in modo sequenziale andare avanti e indietro alle fasi già completate.

È ridicolo testare manualmente questa cosa, quindi ho scritto un test utilizzando Behat con Mink e Selenium2.

Ho solo 1 test ora, che completa tutte le 12 fasi del modulo. Per andare a un punto specifico nel processo di compilazione del modulo, ho creato una definizione di passaggio che fa in modo che il webdriver attenda 1 ora (ride di me). Quando ho bisogno di testare una fase specifica, aggiungo questo passaggio dove voglio che il selenio si fermi, lasciando aperta la finestra del browser in modo da poter fare tutto ciò che voglio manualmente senza dover riempire tutti i campi precedenti.

Risparmia un sacco di tempo, ma si sente stupido. Ho delle ragioni per farlo:

deve essere fatto al più presto.
Non riesco a testare ogni passaggio separato nel modulo.
Non riesco a riutilizzare parti del processo di riempimento senza dover scrivere un bel po 'di codice PHP. Ora il mio test è di appena ~ 120 righe scritte in lingua Gherkin.

La versione semplificata della mia domanda è: come devo testarlo?

Posso pensare a diversi modi:

Modifica il codice per consentire le fasi di salto. Questo può essere fatto in modo sicuro rilevando i parametri dell'ambiente con l'applicazione e decidendo se il client (webdriver o utente) può o non può saltare le fasi, quindi saltare non è consentito in un ambiente di produzione.
Basta scrivere più test con un sacco di copia-incolla e diventare una scimmia più grande.
Scrivi le definizioni dei passaggi per completare separatamente le fasi specifiche. Quindi, potrei semplicemente scrivere
```
When I complete phase 1
And complete phase 2
And complete phase 3
...
```
nei test.

Quindi, la versione completa della mia domanda è: quale modo è preferibile e quali (dis) vantaggi ogni modo ha? Forse ci sono altri modi, come progettare un'applicazione in un modo completamente diverso così non ci sono problemi di questo tipo.

design web-applications automation acceptance-testing

posta scriptin 20.12.2012 - 19:00

fonte

1 risposta

Leggi altre domande sui tag design web-applications automation acceptance-testing

Dovremmo convalidare una transizione di stato prima di tentare nel modello di stato? Kiln - Limitazione Mercurial e Git [chiuso]

score 5 · Accepted Answer

Prima di tutto, non modificare il codice per comodità di test. Onestamente, questo è un caso della coda che scuote il cane.

Ci sono alcuni casi in cui è giustificabile ristrutturare il codice per semplificare i test, ma per quello che hai esposto, è un'idea orribile. Quando ricevi un "regalo" legacy come questo, il primo ordine del giorno è quello di cambiare nulla finché non puoi iniziare a inscatolarne gli effetti.

Altro per la tua domanda ...

Adotta un approccio per strutturare i passaggi del test attorno alle fasi di input. Faremo finta che ci siano requisiti aziendali che indicano che gli input dovrebbero essere ricevuti nel modo che hai descritto. (Ok, sappiamo che è una bugia, ma diamo il beneficio del dubbio).

Questa finzione rende in realtà più facile testare il codice. È una regola aziendale implicita che la fase 2 non possa essere testata a meno che la fase 1 non sia completa E corretta. Fai un passo indietro e vedrai che questo semplifica drasticamente il numero di scenari che devi testare. I test nella fase 2 ora possono assumere che tutto sia kosher all'interno della fase 1 perché le regole aziendali dicono che non è possibile procedere alla fase 2 a meno che 1 non sia a posto.

Sembra che tu stia adottando l'approccio giusto per testare le cose, visti i vincoli a cui sei sottoposto. In altre parole: triage. In un mondo ideale potresti riscrivere tutto e scrivere allo stesso tempo casi di test perfetti. Nel frattempo, le scadenze si profilano e gli aggiornamenti devono essere spediti. Inizia con i test case "heavy hitter" e aggiungi sfumature aggiuntive quando il tempo lo consente. Questo onestamente non è diverso dalla maggior parte degli altri sviluppi. Il tempo è generalmente un lusso che un progetto non può permettersi.

I tuoi sentimenti di disagio sono il conflitto tra il modo ideale di testare il codice e il modo pragmatico di testare il codice. Questa è una reazione abbastanza normale ai compromessi presi nel processo di sviluppo. Commenta le scorciatoie da eseguire, indica le aree da migliorare e continua ad aumentare.

Per facilitare il test delle fasi successive, crea sezioni riutilizzabili del codice del mock-up che completino correttamente le sezioni precedenti. Quindi, per testare la fase 3, farai due chiamate per completare correttamente la fase 1 e 2 e permettere che la fase 3 sia esposta. È uno smidge di un hack, ma riflette anche le regole di business coinvolte nell'applicazione. In altre parole, estrai il tuo test singolo esistente in 12 componenti. Ciò ti consentirà di esercitare le fasi a valle più facilmente / indipendentemente.