39

Cuke4Nuke と SpecFlow のどちらを使用するかを決定しようとしています。それぞれの長所/短所は何ですか? どちらが優れているか、その理由についての意見。

ありがとう！

4

6 に答える 6

60

（私はSpecFlowに携わっているので偏見があるかもしれませんが、ここで私の考えを...）

Cuke4Nuke は Cucumber に非常に近いです。これにより、多くの利点が約束されます。

  • 互換性
  • Cucumber が進化したときに Cucumber から新しい機能を取得する (少なくとも理論的には、言語サポートはその例です)
  • Cucumber コミュニティと Cucumber エコシステムの真の一員であること

ただし、これにはいくつかの潜在的な欠点もあります。

  • ルビーは必需品
  • より多くのインフラストラクチャ (Ruby、Wire-Protocol、コマンドライン統合など) が関与するため、ソリューション全体の複雑さが増し、チェーン内の何かが失敗する可能性が高くなります。
  • デバッグは可能ですが、少し面倒です
  • dos-commandline でシナリオを実行するのは単純に見苦しく、一部の文字 (ドイツ語のウムラウテ) にはまだ問題があります。私の場合、Cucumberのソリューションは cuke4nuke では機能しませんでした。
  • 継続的なビルドとの統合は、自分で解決する必要があるものです

SpecFlow は Cucumber とは別のプロジェクトです。できる限り Cucumber に近づけようとしますが、ギャップがあり、ギャップがあります。言語レベルでの互換性を向上させるために、Cucumber と同じパーサーを使用する計画があります。

SpecFlow は、次の利点を提供しようとします。

  • 純粋な .NET ソリューション (したがって、Ruby のインストールは不要であり、Ruby は実行時に関与しません)
  • VisualStudio との基本的な統合があります (これを進化させる計画があります)。
  • シナリオは基本的に UnitTests であり、既存のインフラストラクチャ (NUnit.Runners、ReSharper、VisualStudio MSTest 統合など) で実行できます。
  • シナリオとステップは、VisualStudio から簡単にデバッグできます (ブレークポイントを設定するだけです)。
  • 単体テストを実行するためのインフラストラクチャがすでに存在することは間違いないため、継続的なビルドへの統合は簡単です。

SpecFlow の欠点として、私は現在見ています:

  • Cucumberほど多くの言語をサポートしていません
  • 現在、「コード生成」ステップが含まれています。VisualStudio を使用する場合、これは透過的であり、VisualStudio を使用せずにこれを行うコマンドラインがありますが、多くの人はコード生成を好みません。
  • 現在、SpecFlow 用の明示的なコマンドライン ランナーはありません。ただし、単体テスト コマンドライン ランナーを使用できます。
  • SpecFlow は Unit-Test フレームワークに依存しており、現在は NUnit と MSTest のみがサポートされています
  • SpecFlow でのレポートは、まだあまり洗練されていません。Cucumber はより多くのオプションを提供していますが、cuke4nuke でそれらがすべて利用可能かどうかはわかりません...
于 2010-01-22T10:27:53.337 に答える
11

jbandi は良い要約を提供します。私はほぼ同じ方法で質問に答えます（もちろん、偏見の反対の免責事項があります）。

Cuke4Nuke の目標は、.NET での Cucumber との完全な互換性を保ちながら、Cucumber コードの複製をできるだけ少なくすることです。したがって、あなたが強調したいくつかのトレードオフ (Ruby への依存など) は、ツールに固有のものです。言語とフォーマッタのサポートのバグや限定的なデバッグ サポートなど、その他の問題は一時的な問題であり、将来のバージョンでは解消される予定です。

Cuke4Nuke が Cucumber のように機能しないといういくつかの問題に遭遇しました。しかし、私は主に英語で仕事をしているので、通常の仕事では言語関連の問題は見られません。修正できるように、これらの問題を再現する手順を歓迎します。(ここではなく、Cuke4Nuke の問題リストを投稿してください。)

于 2010-01-23T11:43:18.793 に答える
11

別の非常に偏った意見: StoryQを試してみてください:)

StoryQ テストは実際にはコードであるため、リファクタリング / IDE サポートが大幅に向上し、既存の単体テスト ランナーに組み込まれるため、CI は簡単です。

プレーンテキストの機能をチェックインするか、コンパイル可能なコードをチェックインするかは、おそらく好みの問題です。しかし、私たちにとっては、ナラティブ メソッドの名前を変更して、すべてのストーリーを自分自身で更新できるようになったことは本当に素晴らしいことでした。

プレーンテキストのシナリオにすでに投資している場合や、ビジネス パーソンにキーボードを提供したい場合は、プレーン テキストのシナリオを StoryQ コードに変換する GUI が実際に提供されています。シンプルな形のインテリセンスさえあります！

BDD への超軽量のエントリ ポイントが必要な場合は、試してみてください :)

于 2010-02-05T17:09:18.897 に答える
7

リチャードから、彼はCuke4Nukeを廃止するつもりであり、Cuk4Nuke機能の一部をSpecFlowに移動することをサポートしていることを理解しています。したがって、明確な答えはSpecFlowです。

于 2011-08-25T06:33:52.050 に答える
7

別の偏った反応: StorEvilは他のすべての .NET BDD ツールを食べます。

利点: StorEvil には独自のコマンドライン ランナーがあり、優れたレポート (Spark ビュー エンジンを使用) があり、最高のプレーンテキスト ->C# 変換および実行エンジンがあります。

また、他のソリューションよりも 100% 悪意があります。

短所: StorEvil は他の人間の言語 (英語を除く) を完全にはサポートしていません。StorEvil の Visual Studio 統合は、まだ他のツールほど優れていません。監視しないと、StorEvil が冷蔵庫のビールを全部飲み干してしまいます。

于 2010-06-29T22:27:28.600 に答える
6

私はCuke4Nukeから始めましたが、その後SpecFlowに亡命しました（申し訳ありませんがRichard;-)

私がその移行を行う主な理由は次のとおりです。

  • SpecFlowには、機能の構文強調表示のための優れたVS2010統合があります。同様の機能を提供するCuke4VSプロジェクトがありますが、VS2010はサポートされていません（または、とにかく最後に調べたときは、かなり最近でした）。
  • SpecFlowでのデバッグテストの方が簡単であることがわかりました（詳しく説明するように言わないでください。そのように見えました...;-)
  • Cuke4NukeにはRubyが必要でした。私はそれで大丈夫でしたが、私が知っているほとんどのC＃開発者は、MS以外の製品、特にRubyに驚かされます。

Specflow / Cucumber/Cuke4Nukeの世界で私がもっと好きなものにはいくつかの問題があります。

  • Specflowのドキュメントは非常に「ライト」です。Cucumberソースから情報を収集し、それらがSpecflowにどのように適用されるかを少し直感的に理解するために一生懸命働く準備をする必要があります。そうは言っても、私と他のほとんどの人は、今後数か月で改善される可能性があるように、ドキュメントを強化する設計をしています。
  • ステータスに応じて色分けされたシナリオの出力を使用して、コマンドラインでCucumber / Cuke4Nukeテストを実行した経験が非常に好きです（上記の誰かがこれをネガティブと見なしているので、コマンドラインの種類によって異なると思います男...）
  • キュウリのコミュニティはより大きく、より多くの活動があり、それは（おそらく）あなたを助けるためにそこにいるより多くの人々につながるようです。

全体として、どちらもソフトウェアの作成方法を改善する可能性があります。

于 2011-02-15T19:04:41.927 に答える