Domanda

Sto cercando di decidere se usare Cuke4Nuke o SpecFlow.Quali sono i pro/contro di ciascuno?Opinioni su cosa sia meglio e perché.

Grazie!

È stato utile?

Soluzione

(Potrei essere di parte perché sono coinvolto con SpecFlow, ma ecco i miei pensieri...)

Cuke4Nuke è molto vicino a Cucumber.Ciò promette molti vantaggi:

  • Compatibilità
  • Ottenere nuove funzionalità da Cucumber quando Cucumber si evolve (almeno in teoria, ma il supporto linguistico ne è un esempio)
  • Essere una parte reale della comunità dei cetrioli e dell'ecosistema dei cetrioli

Tuttavia questo comporta anche alcuni potenziali svantaggi:

  • Il rubino è una necessità
  • Poiché è coinvolta più infrastruttura (Ruby, Wire-Protocol, integrazione della riga di comando...), la complessità dell'intera soluzione aumenta e aumentano le possibilità che qualcosa nella catena non funzioni
  • Il debug è possibile ma è un po' complicato problemi
  • Eseguire scenari sulla riga di comando dos è semplicemente brutto e ho ancora problemi con alcuni caratteri (Umlaute tedesco).IL soluzioni da Cucumber non ha funzionato per cuke4nuke nel mio caso.
  • L'integrazione con la tua build continua è qualcosa che devi elaborare da solo

SpecFlow è un progetto separato da Cucumber.Cerca di essere il più vicino possibile a Cucumber, ma ci sono e ci saranno delle lacune.Si prevede di utilizzare lo stesso parser di Cucumber, per migliorare la compatibilità a livello linguistico.

SpecFlow cerca di offrire i seguenti vantaggi:

  • Una soluzione .NET pura (quindi non è necessaria l'installazione di Ruby e Ruby non è coinvolto in fase di runtime)
  • Esiste un'integrazione di base con VisualStudio (e ci sono piani per evolverla)
  • Gli scenari sono fondamentalmente UnitTest e possono essere eseguiti con l'infrastruttura esistente (NUnit.Runners, ReSharper, VisualStudio MSTest Integration...)
  • Scenari e passaggi sono facilmente eseguibili da VisualStudio (basta impostare un punto di interruzione)
  • L'integrazione nella creazione continua dovrebbe essere un gioco da ragazzi, poiché l'infrastruttura per eseguire i test unitari è sicuramente già presente

Come svantaggi di SpecFlow vedo attualmente:

  • Non supporta tante lingue quanto Cucumber
  • Attualmente è coinvolta una fase di "generazione del codice".Questo è trasparente quando si utilizza VisualStudio ed esiste una riga di comando per farlo senza VisualStudio, ma a molte persone non piace la generazione di codice.
  • Attualmente non esiste un programma di esecuzione della riga di comando esplicito per SpecFlow.Tuttavia puoi utilizzare il runner della riga di comando del test unitario.
  • SpecFlow dipende da un framework Unit-Test e attualmente sono supportati solo NUnit e MSTest
  • Il reporting in SpecFlow non è ancora molto sofisticato.Cucumber offre più opzioni, tuttavia non so se sono tutte disponibili in cuke4nuke...

Altri suggerimenti

jbandi dà una buona sintesi. Rispondo alla domanda più o meno allo stesso modo (con il disclaimer contrario per partito preso, ovviamente).

L'obiettivo per Cuke4Nuke è la compatibilità cetriolo completa in .NET durante la duplicazione da poco codice cetriolo possibile. Pertanto, alcuni dei compromessi si evidenziati-es. Ruby dipendenze sono inerenti allo strumento. Altri, come gli insetti in lingua e il supporto di formattazione e il supporto di debug limitata, sono problemi temporanei e andrà via con le versioni future.

ho incontrato un paio di questioni in cui Cuke4Nuke non funziona abbastanza come cetriolo. Ma, come io lavoro principalmente in inglese, non vedo le questioni relative alla lingua nel mio lavoro normale. Mi piacerebbe benvenuto passi per riprodurre qualsiasi di questi problemi in modo che io possa risolvere. (Si prega di inviare a loro l'Cuke4Nuke elenco di problemi , non qui.)

Un altro parere pesantemente di parte: Prova StoryQ :)

StoryQ test sono in realtà il codice, in modo da ottenere un supporto molto migliore refactoring / IDE, e incorpora all'interno del vostro corridore test di unità esistente, in modo da C'è un gioco da ragazzi.

E 'probabilmente una questione di preferenza se si preferisce il check-in funzioni di testo o codice compilabile. Ma per noi abbiamo scoperto che è stato davvero bello essere in grado di rinominare i metodi narrativi e hanno tutte le storie si aggiornano.

V'è in realtà una GUI a condizione che permette di convertire gli scenari di testo in codice StoryQ per voi, se avete già un investimento in scenari in chiaro o se vuoi dare la tastiera per i vostri uomini d'affari. E 'anche avuto una semplice forma di Intellisense!

Dare un andare se si vuole un punto di ingresso ultra-leggero in BDD:)

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

Vantaggi :. StorEvil ha una propria corridore della riga di comando, ha una bella segnalazione (utilizzando il motore di visualizzazione Spark), e ha la migliore> C # di traduzione ed esecuzione del motore plaintext-

Inoltre, ha 100% in più male di qualsiasi altra soluzione.

Svantaggi : StorEvil non supporta completamente altri linguaggi umani (tranne inglese). integrazione di Visual Studio di StorEvil non è ancora bello come gli altri strumenti. StorEvil berrà tutta la birra in frigo, se non mantenere un occhio su di esso.

Ho capito da Richard che ha intenzione di interrompere la Cuke4Nuke e sostiene spostando alcuni dei Cuk4Nuke funzioni in SpecFlow. Quindi la risposta chiara ora è SpecFlow.

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 evidenziare la sintassi di funzioni. C'è un progetto che offre Cuke4VS simile ma non ha potuto non avere il supporto VS2010 (o non ultima volta che ho guardato in ogni caso, che era abbastanza recente)
  • Ho trovato prove di debug in SpecFlow per essere più facile (non chiedetemi di elaborare, mi sembrava in quel modo ...; -)
  • Cuke4Nuke bisogno di Ruby. Ero d'accordo con questo, ma la maggior parte degli sviluppatori C # che conosco avrai una fifa blu per tutti i prodotti non-MS, Ruby in particolare.

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

  • la documentazione del Specflow è abbastanza 'lite' - si dovrà essere pronti a lavorare sodo per raccogliere informazioni da fonti cetriolo e intuire un po 'come si applicano al Specflow. Detto questo io e pochi altri hanno disegni su rinforzando la documentazione in modo che possano migliorare nei prossimi mesi.
  • preferisco di gran lunga l'esperienza di esecuzione dei test cetriolo / Cuke4Nuke sulla riga di comando con la loro uscita del colore scenari codificati in base allo stato (lo so che qualcuno sopra vede questo come un fatto negativo quindi immagino che dipende se sei un comando linea tipo di ragazzo ...)
  • La comunità cetriolo è più grande e non c'è più l'attività sembra che (forse) si traduce in maggior numero di persone là fuori per aiutarvi.

Tutto sommato entrambi hanno il potenziale per migliorare il nostro modo di scrivere software.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top