Come scegliere tra diversi tipi di test con SpecFlow, cetrioli o altri framework di test di accettazione BDD?

Question

Sto cercando di esempi SpecFlow, e del campione MVC contiene diverse alternative per il test:

• Test di collaudo basato sulla validazione dei risultati generati dal controller;
• test di integrazione utilizzando MvcIntegrationTestFramework;
• prove di collaudo automatico utilizzando Selenio;
• prove di accettazione manuale quando tester è richiesto di risultati confermano manualmente.

Devo dire che sono molto impressionato da quanto bene esempi SpecFlow sono scritti (e sono riuscito a farli funzionare in pochi minuti dopo il download, appena avuto per configurare un database e installare Selenio Remote Control Server). Guardando le alternative di test posso vedere che la maggior parte di loro si completano a vicenda piuttosto che essere un'alternativa. Mi vengono in mente le seguenti combinazioni di questi test:

• I regolatori sono testati in stile TDD piuttosto che utilizzare SpecFlow (credo Premesso / Quando / Poi tipo di test dovrebbe essere applicato su una maggiore, end-to-end di livello, che devono fornire una buona copertura di codice per rispettivi componenti;
• MvcIntegrationTestFramework è utile quando si eseguono i test di integrazione durante le sessioni di sviluppo, questi test sono anche parte delle generazioni quotidiana;
• Anche se i test Selenium-based sono automatizzati, sono lenti e sono principalmente per essere avviato durante le sessioni di QA, in modo rapido validate che non c'è logica sono rotti in pagine e workflow sito;
• prove di accettazione manuale quando tester è richiesto di confermare la validità risultato sono principalmente per verificare la pagina aspetto grafico.

Se si utilizza SpecFlow, cetrioli o altri framework di test di accettazione BDD in voi lo sviluppo Web, ti invitiamo a condividere le vostre pratiche in materia di scegliere tra diversi tipi di test.

Grazie in anticipo.

Answer 1

E 'tutti i comportamenti.

Dato un particolare contesto, quando si verifica un evento (entro un determinato campo di applicazione), poi qualche risultato dovrebbe accadere.

L'ambito può essere una intera applicazione, una parte di un sistema o una singola classe. Anche una funzione si comporta in questo modo, con ingressi come contesto e l'output come outcome (è possibile utilizzare BDD per il linguaggio funzionale, come pure!)

Io tendo ad usare quadri unitari (NUnit, JUnit, RSpec, etc.) a livello di classe o l'integrazione, perché il pubblico è tecnica. A volte mi documento un dato / Quando / Poi nei commenti.

A livello scenario, cerco di scoprire chi realmente vuole aiutare lettura o scrittura degli scenari. Anche le parti interessate di business può leggere il testo che contiene un paio di punti e parentesi, in modo che il motivo principale per avere un quadro il linguaggio naturale come MSpec o JBehave è che se vogliono scrivere scenari stessi, o mostrarle a persone che saranno davvero essere messi fuori dai punti e staffe.

Dopo di che, guardo come il quadro sarà giocare con il sistema di compilazione, e come noi daremo la possibilità di leggere o scrivere a seconda dei casi alle parti interessate.

Ecco un esempio che ho scritto per mostrare il tipo di cosa si può fare con gli scenari che utilizzano DSL semplici. Questo è solo scritto in NUnit.

Ecco un esempio nella stessa base di codice Mostra Dato, Quando, poi in a livello di classe esempio commenti.

I astratto i passi dietro, poi ho messo schermi o pagine dietro quelle, poi negli schermi e le pagine che io chiamo qualunque framework per l'automazione sto usando - che potrebbe essere Selenio, Watir, Webrat, Microsoft UI Automation, ecc

L'esempio ho fornito sé è uno strumento di automazione, così gli scenari dimostrano il comportamento dello strumento di automazione attraverso dimostrare il comportamento di una GUI falso, solo nel caso in cui si confonde. Speranza che aiuta in ogni modo!

Answer 2

Dal momento che prove di collaudo sono una sorta di test funzionali, l'obiettivo generale è quello di testare l'applicazione con loro end-to-end. D'altra parte, potrebbe essere necessario prendere in considerazione l'efficienza (quanto sforzo è quello di implementare l'automazione dei test), manutenibilità, prestazioni e l'affidabilità del test automation. E 'anche importante che l'automazione di test può essere facilmente inserita nel processo di sviluppo, in modo che supporti una sorta di "test primo" approccio (al sostegno allo sviluppo al di fuori-in).

Quindi questo è un compromesso, che può essere diverso per ogni situazione (è per questo che abbiamo fornito le alternative).

Sono abbastanza sicuro, che oggi l'opzione più ampiamente raccordo è quello di testare a livello di controller. (Forse più tardi come interfaccia utente e interfaccia utente framework di automazione si evolveranno, questo cambierà.)