Cuke4Nuke o SpecFlow?

Question

Sto cercando di decidere se utilizzare Cuke4Nuke o SpecFlow. Quali sono i pro/contro di ciascuno? Opinioni su cui è meglio e perché.

Grazie!

Answer 1

(potrei essere prevenuto perché io sono coinvolto con SpecFlow, ma qui il mio pensiero ...)

Cuke4Nuke è molto vicino al cetriolo. Questo promette un sacco di vantaggi:

• Compatibilità
• Ottenere nuove funzionalità da cetriolo quando si evolve cetriolo (almeno in teoria, ma il supporto della lingua è un esempio di questo)
• Essendo una vera e propria parte del comunità di cetriolo e l'ecosistema cetriolo

Tuttavia, questo viene fornito con alcuni potenziali svantaggi:

• Ruby è una necessità
• Da più infrastrutture (Ruby, Wire-protocollo, l'integrazione della riga di comando ...) è coinvolto, la complessità della intera soluzione si alza, e le probabilità che qualcosa nella catena sta fallendo aumento
• Il debug è possibile ma un po 'di hassle
• Gli scenari di esecuzione sulla linea di comando dos sono semplicemente brutti e ho ancora problemi con alcuni caratteri (tedesco Umlaute). Il solutions di Cucumber non ha funzionato per cuke4nuke nel mio caso.
• integrazione con la costruzione del continuo è qualcosa che si deve lavorare da soli

SpecFlow è un progetto separato da cetriolo. Cerca di essere il più vicino possibile a Cucumber, ma ci sono e ci saranno lacune. Ci sono piani per utilizzare lo stesso parser di Cetriolo, per migliorare la compatibilità a livello di lingua.

SpecFlow cerca di offrire i seguenti vantaggi:

• Una soluzione .NET puro (quindi nessuna installazione di Ruby è necessaria e Ruby non è coinvolto in fase di esecuzione)
• C'è un'integrazione di base con VisualStudio (e non ci sono piani per evolvere questo)
• Gli scenari sono fondamentalmente Unittests e possono essere eseguiti con l'infrastruttura esistente (NUnit.Runners, ReSharper, VisualStudio MSTest integrazione ...)
• Scenari e passi sono facilmente debuggable di VisualStud io (è sufficiente impostare un punto di interruzione)
• integrazione nella vostra accumulo continuo dovrebbe essere un gioco da ragazzi, poiché l'infrastruttura per eseguire unità di test è sicuramente c'è già

Come svantaggi di SpecFlow vedo attualmente:

• Non supporta tutte le lingue di Cucumber
• Attualmente è in corso un passaggio di "generazione del codice".Questo è trasparente quando si utilizza VisualStudio e c'è una riga di comando per farlo senza VisualStudio, ma a molte persone non piace la generazione del codice.
• Attualmente non esiste un programma di esecuzione della riga di comando esplicito per SpecFlow. Comunque puoi usare il tuo runner della linea di test unit-test.
• SpecFlow dipende da un framework Unit-Test e al momento sono supportati solo NUnit e MSTest
• Il report in SpecFlow non è ancora molto sofisticato. Cetriolo non offre più opzioni, tuttavia non so se sono tutti disponibili in cuke4nuke ...

Answer 2

jbandi dà una buona sintesi. Rispondo alla domanda più o meno allo stesso modo (con l'opposto disclaimer per pregiudizi, ovviamente).

L'obiettivo per Cuke4Nuke è la completa compatibilità con Cucumber in .NET, duplicando il più possibile il codice Cucumber. Pertanto, alcuni dei compromessi che hai evidenziato, ad es. la dipendenza da Ruby sono inerenti allo strumento. Altri, come bug nel supporto di lingua e formattazione e supporto di debug limitato, sono problemi temporanei e andranno via con versioni future.

Ho riscontrato alcuni problemi in cui Cuke4Nuke non funziona come Cucumber. Ma poiché lavoro principalmente in inglese, non vedo i problemi relativi alla lingua nel mio normale lavoro. Sarei benvenuto nei passaggi per riprodurre uno di questi problemi in modo da poterli risolvere. (Si prega di inviare a loro the Cuke4Nuke issues list, non qui.)

Answer 3

Un altro parere pesantemente di parte: Prova StoryQ :)

test StoryQ sono in realtà il codice, in modo da ottenere un supporto molto migliore refactoring/IDE, e incorpora nel nostro PC unità di test runner, quindi CI è un gioco da ragazzi.

Probabilmente è una questione di preferenza se preferisci controllare funzionalità in testo normale o codice compilabile. Ma per noi abbiamo scoperto che è stato davvero bello poter rinominare i metodi narrativi e far sì che tutte le storie si aggiornassero da sole.

Esiste in realtà una GUI che convertirà scenari di testo normale in codice StoryQ per te, se hai già un investimento in scenari in chiaro o se desideri dare la tastiera ai tuoi uomini d'affari. Ha persino una semplice forma di intelligenza!

dare un andare, se si desidera un punto di ingresso ultra-leggero in BDD :)

Answer 4

Un'altra risposta di parte: StorEvil mangia a tutti gli altri strumenti .NET BDD.

Vantaggi: StorEvil dispone di un proprio corridore della riga di comando, ha una bella segnalazione (utilizzando il motore di visualizzazione Spark), e ha il miglior motore di C# di traduzione ed esecuzione plaintext->.

Inoltre, ha il 100% di danni in più rispetto a qualsiasi altra soluzione.

Svantaggi: StorEvil non supporta completamente altre lingue umane (tranne l'inglese). L'integrazione di Visual Studio di VisualEvil non è ancora bella come gli altri strumenti. StorEvil berrà tutta la birra nel frigo se non la tenete d'occhio.

Answer 5

ho iniziato con Cuke4Nuke ma da allora disertato SpecFlow (scusate Richard ;-)

Le ragioni principali per me fare questa transizione sono stati:

• SpecFlow è bella integrazione VS2010 per l'evidenziazione della sintassi di Caratteristiche. C'è un progetto Cuke4VS che offre simili ma non ha avuto il supporto VS2010 (o meno quando l'ho guardato l'ultima volta, che era abbastanza recente)
• Ho trovato test di debug in SpecFlow per essere più facile (non chiedere me per elaborare, sembrava proprio così ... ;-)
• Cuke4Nuke aveva bisogno di Ruby. Ero d'accordo, ma la maggior parte degli sviluppatori di C# che conosco sono spaventati da qualsiasi prodotto non MS, in particolare Ruby.

Ci sono alcuni problemi con Specflow/cose che mi piace di meglio al mondo Cetriolo/Cuke4Nuke:

• documentazione del Specflow è abbastanza 'lite' - si dovrà essere pronti a lavorare sodo per raccogliere informazioni dalle fonti di Cucumber e intuire un po 'come si applicano a Specflow. Questo ha detto che io e pochi altri abbiamo progetti per rinforzare la documentazione in modo che possa migliorare nei prossimi mesi.
• Preferisco di gran lunga l'esperienza dell'esecuzione di test Cucumber/Cuke4Nuke sulla riga di comando con il loro output degli scenari codificati in base allo stato (so che qualcuno sopra lo vede come un negativo quindi immagino dipenda dal fatto che tu sia un comando tipo di linea di ragazzo ...)
• La comunità di Cucumber è più grande e c'è più attività sembra che (possibilmente) si traduca in più persone là fuori per aiutarti.

Nel complesso, entrambi hanno il potenziale per migliorare il modo in cui scriviamo il software.

Answer 6

Capisco da Richard che intende interrompere Cuke4Nuke e supporta lo spostamento di alcune delle funzionalità di Cuk4Nuke in SpecFlow. Quindi la risposta chiara ora è SpecFlow.