3

私はrspec[Ruby]とspecs[Scala]に少し精通しています。昨日、キュウリの家庭教師をパスしました。私がCucumberについて嫌いだったのは、シナリオの記述に加えて（specまたはxUnitスタイルのテストで行うように）、間接参照の追加レイヤーを実装する必要があることです。シナリオのステップをルビー式に変換します。私にとって、間接参照の不要な（？）余分なレイヤーを作成することは、「軽量」のルビーウェイではなく、「重量級」のJ2EEウェイのように感じます。「ドメインエキスパート」による理解可能性は、Cucumberの唯一の利点ですか？それとも、開発者/テスターに​​とっても明らかではない（技術的な？）利点がいくつかありますか？

4

3 に答える 3

6

Cucumberは、誰もが理解できるシナリオを共同で作成することにより、開発者とテスターのシステムに対する理解を深めることにビジネスの利害関係者を関与させるのに役立つように設計されています。

ビジネスの利害関係者を関与させるという行為は、誰もがよりよく理解し、同じ言語を共有し、その言語をコードに取り入れ始めるために報われます（ドメイン駆動設計の「ユビキタス言語」を参照）。これにより、より良い見積もり、範囲の評価につながる可能性があります。同じ目標を達成するためのオプションに関する会話など。

目標を達成する方法は確かに他にもあります。たとえば、C＃プロジェクトでは、シナリオについて説明し、wikiに記述してから、このような小さなカスタムドメイン固有言語を使用して実装します。Rubyでも同じことができます。

BDDは、私たちが何をしているのかを知っていると思った場所を学習するプロセスですが、私たちが間違っていたことが判明しました-無知の発見。機能インジェクションとユニットレベルの例では、これはプロジェクトのビジョン自体に至るまで、複数のレベルの粒度で発生します。それはそれ自体で報われる傾向がありますが、BDDを実行するためにBDDフレームワークは必要ありません。

BDDでの会話は重要な部分であり、それらをキャプチャするために使用するツールではありません（JBehaveの作成を支援しましたが、これは真実であると今でも信じています）。回帰テストの自動化は、コードベースの成長に伴って発生する手作業を削減するためにも重要です。Cucumber、DSL、およびその他のBDDツールは、これを非常に優れた副産物として提供し、共有された理解を追跡して追い出すのにも役立ちます。 。

編集：ステップの再利用も重要ですが、BDDフレームワークを使用するかDSLを使用するかはそれほど違いはありません。これは、DSLと、すべてのユーザーインタラクションを手続き的に模倣することの違いを生みます。

于 2010-11-18T16:43:24.853 に答える
6

BDDは、実用的な観点から、TDDと非常に同義です。Rspecは、Cucumberと同様にBDDテストフレームワークです。

利害関係者がキュウリの受け入れ仕様を読んで理解できることは確かに重要な利点ですが、この事実だけではキュウリの真のメリットは得られません。機能とシナリオは、それらのために行われている作業がチームの開発サイクルのバリューストリームを移動するにつれて、ある程度具体的に成長するはずです。

一部のチームでは、サイクルの開始時にアナリストが作業を調査している場合があります。このアナリストがガーキンの受け入れ仕様を作成することもありますが、最初のドラフトを作成する人は誰でも、かなり粗いものになると予想されます。彼らはすべての不幸な道をカバーするわけではありません。

開発者が作業を引き受けると、エッジケースや欠落しているシナリオを発見することがよくあります。この時点で、彼らはアナリストとベースに触れることができ、そのような会話の結果はキュウリの特徴に書き込まれる必要があります。

私の経験では、テスターはさらに批判的な目を育ててきたので、テスターがさらに多くのシナリオや機能を追加するのを見るのは珍しいことではありません。テスターは欠陥を発見することもあります。欠陥は、リグレッションから保護するためにキュークに追加する必要があります。

重要なのは、コードの実行可能ドキュメントを提供することに加えて、Cucumberは、開発中の機能に対するチームの会話の状態のリポジトリも提供するということです。

これらすべてに確かに余分なオーバーヘッドがあります。ただし、Cucumberが合理化に役立つ可能性のある、チームのプロセスにすでにどの程度のオーバーヘッドがあるかを検討する価値があります。Cucumberは、チームルーム内外の機能に関するコミュニケーションで発生するスラッシュの量を減らすのに役立つことがわかりました。

また、キュウリはフルスタックの受け入れテストを目的としているため、単体テストに比べて細かくする必要があります。そして、キュウリはユニットテストと統合テストの良い代替品ではありません。また、アプリのUIの美的側面を検証するためにキュウリを使用することはお勧めしません。これを使用して、ユーザーがアプリを使用するときに実行する可能性のあるアクションを検証します。

于 2010-11-18T21:51:54.647 に答える
2

それはあなたが何を達成したいかによります。

きゅうりはオーバーヘッドを追加し、慣れるのが難しい場合があり、習得するには時間がかかります。

ドメインの専門家がテストを読めるようにしたい場合は、ぜひ試してみてください。

一方、開発者だけがテストを読んでいる場合は、おそらくrspec / unit-test/etcに固執することができます。そして、それらのフレームワークで統合テストを記述します。ただし、キュウリを使用すると、より読みやすい高レベルのドキュメントを作成できる場合があります。たとえば、キュ​​ウリのrspec2コア機能の説明を参照してください。

于 2010-11-16T14:25:55.130 に答える