BDD e test funzionali

Question

Sto iniziando a comprare in BDD. Fondamentalmente, a quanto ho capito, si scrive uno scenario che descrive i criteri di accettazione per certe storie. Si parte da semplici test, dall'esterno, usando i mock al posto delle classi che non si implementano ancora. Mentre avanzi, dovresti sostituire i mock con classi reali. Da Introduction to BDD:

Inizialmente, i frammenti sono implementato usando mock per impostare un account essere in credito o una carta per sia valida. Questi formano i punti di partenza per il comportamento di implementazione. Come di implementare l'applicazione, le Givens ei risultati vengono modificati per utilizzare le classi attuali Abbiamo attuate, in modo che per il momento lo scenario è completato, hanno diventare adeguati funzionali test end-to-end.

La mia domanda è: una volta completata l'implementazione di uno scenario, tutte le classi utilizzate dovrebbero essere reali, come nei test di integrazione? Ad esempio, se si utilizza DB, il codice dovrebbe essere scritto su un DB reale (ma leggero in memoria)? Alla fine, dovresti avere qualche mock nei tuoi test end-to-end?

Answer 1

Beh, dipende :-) Da quello che ho capito, i test prodotti da BDD sono ancora unit test, quindi dovresti usare i mock per eliminare la dipendenza da fattori esterni come DB.

In tutti i test di integrazione/funzionalità a tutti gli effetti, tuttavia, è necessario testare ovviamente l'intero sistema di produzione, senza alcun errore.

Answer 2

I test di integrazione possono contenere stub/mock per simulare il codice/i componenti all'esterno dei moduli che si stanno integrando.

Tuttavia, IMHO il test end-to-end non deve significare stubs/mock lungo la strada, ma solo il codice di produzione. O in altre parole - se i mock sono presenti - non è davvero un test end-to-end.

Answer 3

Sono d'accordo con Peter e Ratkok. Penso che tu mantenga i mock per sempre, quindi hai sempre dei test unitari.

Separatamente, è opportuno disporre inoltre di test di integrazione (no mock, uso di un DB, ecc. Ecc.).

È anche possibile trovare inter-servizi utili a volte (deridere un pezzo di codice dipendente (DOC), ma non un altro).

Answer 4

Ho appena esaminato la BDD e in particolare JBehave. Lavoro in imprese abbastanza grandi con un sacco di cascate, persone orientate alla cerimonia. Sto osservando il BDD come un modo per portare le aziende a utilizzare i casi e poi trasformarsi direttamente in test che lo sviluppatore può trasformare in test di unità o di integrazione.

BDD mi sembra non solo un modo per aiutare gli sviluppatori a comprendere ciò che l'azienda vuole, ma anche un modo per garantire che tali requisiti siano rappresentati in modo accurato.

La mia opinione è che se si ha a che fare con mock allora si stanno facendo dei test unitari. Avete bisogno di entrambi i test unitari per testare i dettagli di un'operazione di classe e le integrazioni per verificare che la classe giochi bene con gli altri. Trovo che gli sviluppatori spesso si infondano tra i due, ma è meglio essere il più chiari possibile e tenerli separati l'uno dall'altro.

Answer 5

Sì, nel momento in cui uno scenario viene eseguito, idealmente tutte le classi saranno reali. Uno scenario esercita il comportamento dal punto di vista dell'utente, quindi il sistema dovrebbe essere come l'utente lo vedrebbe.

Nei primi tempi del BDD eravamo soliti iniziare con i mock negli scenari. Non mi preoccupo più di questo, perché è un sacco di lavoro da mantenere beffardo mentre scendi i livelli. Invece, a volte farò cose come dati o comportamenti hard-code se mi consentirà di ottenere un feedback dagli stakeholder più rapidamente.

Mangiamo ancora i mock nei test unitari.

Per cose come i database, certo, è possibile utilizzare un DB in memoria o qualsiasi altra cosa aiuti a ottenere un feedback più veloce. A un certo punto dovresti probabilmente eseguire i tuoi scenari su un sistema il più vicino possibile alla produzione. Se questo è troppo lento, potresti farlo durante la notte invece che come parte del normale ciclo di build.

Per quanto riguarda ciò che "dovresti" fare, scrivere il codice giusto è molto più difficile della scrittura del codice giusto. Mi preoccupo di utilizzare i miei scenari per ottenere feedback dagli stakeholder e dagli utenti prima che mi preoccupi di quanto il mio ambiente sia vicino a un ambiente di produzione. Quando arrivi al punto in cui le modifiche vengono distribuite ogni paio di settimane, certo, allora probabilmente vuoi più certezza che non stai introducendo bug.

Buona fortuna!