Quali sono le differenze tra i framework BDD per Java? [chiuso]

Quali sono i pro e i contro di ogni framework BDD ( Behaviour Driven Development ) per Java?

Ne ho trovati alcuni qui , ad esempio.

Ha senso utilizzare un framework BDD se utilizzo già una libreria mocking (es. Mockito )?

Ho appena finito di confrontare tre framework BDD per Java. Ovviamente i miei risultati hanno una data di scadenza abbastanza breve.

Concordion

• Molto flessibile
• Report molto carino
• Bello il framework dei plugin
• Scarsamente documentato. Ho dovuto leggere la fonte per capirlo (fortunatamente la sua qualità estremamente buona).
• Sembrava probabile che i dispositivi finissero per essere strettamente accoppiati all'html.

EasyB

• Curva di apprendimento molto superficiale (anche per sviluppatori non Groovy)
• Integrazione DBUnit estremamente potente
• Apparentemente nessun supporto per i parametri (porta a storie molto vaghe o duplicazioni tra testo e codice (modifica: in realtà c'è ma la documentazione era ben nascosta).
• Storia e Codice sono strettamente collegati (stesso file)
• Output di report molto semplice
• Impossibile far funzionare il plugin IntelliJ
• Comunità inattiva (il plugin Maven sembra non funzionare da tre mesi - non molti esempi di codice su cui attingere)

JBehave

• Estremamente potente e flessibile (es. Riduzione piastra caldaia tramite composizione di piani come prerequisiti)
• Documentazione ed esempi estesi (se frammentati)
• Ampio (se schiacciante) supporto per diversi framework e ambienti
• Eccellente separazione dei file della storia dal codice
• Sembra avere una comunità piuttosto attiva e molti più esempi e discussioni su di essa sul web.
• Una curva di apprendimento piuttosto ripida (mi ci è voluto 3-4 volte più tempo per capirlo rispetto a Concordion / EasyB)

Non ho avuto la possibilità di provare Cuke4Duke di JDave come avrei voluto, ma probabilmente spingerò per JBehave in questo momento.

"pro e contro" potrebbero essere cose diverse per persone diverse. Di solito do un'occhiata

• attività di sviluppo , ad esempio, sono probabili nuove versioni o è l'ultima versione di 2 anni.
• maturità , ad esempio da quanto tempo esiste, ci sono tutorial e forse anche libri disponibili. (Non leggo questi libri, è solo un segno di adozione.)
• supporto per strumenti , ad es. esiste un plugin Eclipse, supporto Ant, ecc
• dimensione delle dipendenze , non mi piacciono i framework forniti di tutto loro. ad esempio, voglio scegliere io stesso il mio quadro beffardo.
• tipo di licenza , questo è importante per me a causa dei termini legali dell'azienda per cui lavoro.
• compatibilità con gli strumenti correlati , ad es. utilizza o meno il linguaggio Gherkin.

E da alcuni framework che ho visto

• Istinto cattivo : ultima attività marzo 2010, buono : patente ASF
• JDave male : viene fornito con matchers e mock, buono : ultima attività gennaio 2011, licenza ASF
• easyb bad : ultima attività ottobre 2010, non sono sicuro : usa Groovy. Questo potrebbe essere ok, ma nel mio caso sarebbe un problema per l'adozione.
• beanpec male : solo una versione nel 2007, questa è morta
• bdoc male : ultima attività gennaio 2010, non sono sicuro : sembra andare dall'altra parte, creando un report dal codice.
• spock cattivo : forse un po 'estremo, questo è un framework di test completo, non solo BDD, buono : molto attivo, molto bello.
• jbehave , la "madre" di tutti i BDD in Java, cattivo : molto potente = licenza complessa, incompatibile (per me), viene fornito con quasi tutte le librerie di test e molto altro, buono : basato su RSpec e quindi compatibile, plug-in eclipse, integrazione maven , comunità molto attiva
• ginkgo4j , un framework BDD per Java anch'esso basato su RSpec di Ruby ma che utilizza Java lambda (invece di annotazioni) per consentire di creare test altamente contestuali e altamente leggibili. Semplice. Molto potente. Licenza open source Apache 2.

Per quanto riguarda le prese in giro: hai sicuramente bisogno anche di un quadro beffardo. I framework BDD ti aiutano solo a scrivere le specifiche, ma alcuni test avranno bisogno di mock o stub, specialmente. quando si progetta dall'alto verso il basso (dalla panoramica ai dettagli).

Qual è il miglior framework BDD da utilizzare con Java? Perché? Quali sono i pro e i contro di ogni framework?

Ecco un collegamento interessante su Concordion vs. Cucumber e Test di accettazione basato su Java

Ne ho trovati un paio qui, ma non sono sicuro di quale scegliere.

Davvero, guarda quello menzionato sopra.

Ha senso utilizzare un framework BDD se utilizzo già una libreria di mocking (es. Mockito)?

Risposta breve: sì, decisamente. In realtà, il test di accettazione utilizzando un framework BDD e il test di unità in isolamento utilizzando oggetti fittizi sono così diversi che non ho davvero la domanda. Il test di accettazione è un test black box, i test vengono utilizzati per verificare che una funzionalità aziendale funzioni e sono scritti idealmente dall'analista aziendale. I test unitari in isolamento che utilizzano mock sono test white box, i test vengono utilizzati per verificare che un'unità funzioni e sono scritti dagli sviluppatori. Entrambi sono utili ma hanno scopi completamente diversi. In altre parole, l'utilizzo di Mockito non sostituisce affatto un framework BDD ed è vero anche il contrario.

Inizialmente ho fatto il mio BDD con jUnit semplice, ma ultimamente ho guardato JDave perché è quasi 1: 1 rispetto a quello che stavo facendo con jUnit. Funziona anche su jUnit, quindi funziona già su Eclipse ed è anche facile da configurare per lavorare su sistemi di integrazione continua come Hudson. Non posso davvero confrontarlo con gli altri, ma le mie esperienze con JDave sono state buone finora.

Oh, e non è mai un'idea stupida usare i mock! Non sono legati specificamente a TDD / BDD, il loro scopo è alleviare il carico di test in generale.

Wow, vedo che l'argomento è caldo, molte buone risposte ...

Ironia a parte, ho scoperto di recente BDD e ho trovato il concetto interessante. Ehi, costringe a scrivere sia i test ... che le specifiche! Per quanto sorprendente possa sembrare, quest'ultimo può anche mancare in alcuni progetti ... O semplicemente mancare della precisione che BDD costringe a introdurre.

L' articolo Behaviour Driven Development riassume il concetto e collega ad alcuni buoni articoli (come quello scritto da Andrew Glover). Inoltre, all'argomento di questo thread, fornisce un elenco piuttosto completo (suppongo) dei framework BDD, molti dei quali sono per Java.
Non risolve il problema della scelta del framework ma almeno faciliterà la ricerca ...

Dal momento che BDD fa molto affidamento sulla leggibilità del codice di prova, suppongo che un buon criterio di scelta sia guardare i tour / tutorial rapidi e vedere quale sembra più adatto al tuo stile. Altri criteri potrebbero essere il fatto che un framework sfrutti strumenti con cui hai familiarità (unit test, mocking), l'utilizzo con IDE e così via.

Ho provato Cucumber-JVM (precedentemente sviluppato come Cuke4Duke). Utilizza Gherkin DSL per le specifiche, memorizzato come testo normale.

Può essere eseguito come test JUnit. Quindi l'unico problema per iniziare a usarlo è fare in modo che gli uomini d'affari o il Product Manager leggano / scrivano .features in Sources.

risultati

Il mio team utilizza JBehave da un po 'di tempo. Utilizza file di testo semplice per memorizzare le specifiche. Ogni passaggio (dato, quando, quindi) viene quindi eseguito da un determinato metodo che può estrarre i parametri dal passaggio. Gli scenari possono essere rientrati e ben formattati, il che aiuta molto se i clienti vogliono verificarli.

Ci sono anche alcuni problemi. Siamo passati a Java 6. A volte alcuni passaggi dello scenario vengono ignorati durante l'esecuzione. Potrebbe causare molti problemi a capire dov'è il bug.

Il mio team ha utilizzato JBehave con successo: ci siamo passati dopo aver utilizzato EasyB e abbiamo trovato i file di scenario in testo semplice più facili da gestire.