16

プロジェクトの受け入れテストにCucumberを使用することを検討しています。

scenarioCucumber に aを書くとき、 , andステートメントfeatureのリストを書きます。GivenWhenThen

cucumber-jvmプロジェクトを使用しているためGiven、、WhenおよびThenステートメントは (JUnit) クラスの Java メソッドに関連しています。

プロジェクトの構造上、//に関連Givenするコードをどのように編成するのが最適かを知りたいです。私の主な関心事は、シナリオの数が非常に重要であり、特に機能間で共有されるアイテムに関して、大きなプロジェクトでキュウリのテストを維持することです。WhenThen

少なくとも 2 つの主なアプローチを確認できます。

  1. 各機能は、独自の JUnit クラスに関連しています。したがって、キュウリ ファイルがある場合は、関連するJUnit クラスと、適切なおよび注釈付きのメソッドfoo/bar/baz.featureを見つけることができます。foo.bar.Baz@Given@When@Then

  2. @Given、@Whenおよび@Thenメソッドを「テーマ別」クラスおよびパッケージに分離します。たとえば、キュ​​ウリのシナリオで statementGiven user "foo" is loggedがある場合、@Given("^user \"([^\"]*)\" is logged$")注釈付きのメソッドはfoo.user.Userクラス メソッドに配置され@Whenますが、同じキュウリのシナリオで後で使用されるメソッドは、別の Java クラスとパッケージに配置される可能性があります (たとえば、foo.car.RentCar) .

私にとっては、キュウリの機能と Java コードとの関係を簡単に作成できるという点で、最初のアプローチが適しているように思えます。しかし欠点は、多くの冗長性やコードの重複が発生する可能性があることです。また、再作成を避けるために、既存のメソッドを見つけるのが難しい場合があります(IDE は役に立ちますが、ここでは Eclipse を使用していますが、既存のステートメント@Givenのリストが表示されないようです?)。Given

複数のキュウリ機能間で条件を共有している場合は、本質的に他のアプローチの方が優れているように思わGivenれるため、コードの重複を避けたいと考えています。ここでの欠点は、@GivenJava メソッドとGivencucumber ステートメントの間のリンクを作成するのが難しい場合があることです (これも IDE が役に立ちますか?)。

私はきゅうりにかなり慣れていないので、私の質問は良い質問ではないかもしれません。時間と経験があれば、構造は自明になりますが、その使用法について良いフィードバックを得たいと思っています...

ありがとう。

4

3 に答える 3

2

質問で提示したオプション＃2と同様に、参照するオブジェクトに従ってコードをグループ化することをお勧めします。理由は次のとおりです。

  • 使用方法と使用場所に基づいてコードを構造化することは、絶対に禁物です。実際には、機能ファイルとコードの間の結合を作成しています。
    製品のコードでそのようなことを想像してみてください。SendEmail()関数は というクラスにはありませんNewEmailScreenCommandsよね? それは中EmailActionsかそのようなものでしょう。
    したがって、ここでも同じことが当てはまります。誰が使用するかではなく、何をするかに従ってコードを構成します。

  • 最初のアプローチでは、機能ファイルの再編成が困難になります。機能ファイルを変更するたびに、コード ファイルを変更する必要があります。

  • コードをテーマごとにグループ化しておくと、DRY がはるかに簡単になります。エンティティを処理するすべてのコードがどこにあるかを正確に把握しているuserため、再利用が容易になります。

私たちのプロジェクトでは、そのアプローチ (つまりBlogPostStepDefinitionsクラス) を使用し、クラスが大きくなりすぎる場合はコードをステップのタイプ (つまりBlogPostGivenStepDefinitions) にさらに分離します。

于 2014-03-06T13:42:18.507 に答える
1

また、受け入れテストに Cucumber-JVM の使用を開始しましたが、コードの編成に関して同様の問題を抱えています。機能ごとに 1 つのステップ定義クラスを持つことを選択しました。現時点では、テストしている機能はそれほど複雑ではなく、完全に分離していないため、これで問題ありません。機能の重複はほとんどありません。

あなたが言及した 2 番目のアプローチの方が優れていると思いますが、1 つのシナリオで複数の異なるステップ定義クラスを結び付けるのは難しいことがよくあります。機能を追加し、通常どおりリファクタリングを開始すると、最適なプロジェクト構造が明確になると思います。

それまでの間、ここにキュウリ用の Eclipse プラグインがあります。

https://github.com/matthewpietal/Eclipse-Plugin-for-Cucumber

構文の強調表示と、機能を作成するときに使用できる既存の手順のリストがあります。

于 2012-10-18T10:09:36.933 に答える
0

私が参加している現在のプロジェクトで、私たちはまったく同じ質問を自問しました。

可能性を少しいじった後、私たちが選んだのは、あなたが公開した両方のソリューションの組み合わせでした.

  • テーマ中心の共通ステップ クラスでステップを再編成する
    • アプリ起動手順
    • セキュリティチェック手順
    • [ランダムな機能に関する懸念をここに配置] ステップ
  • シナリオのクラス (および場合によっては機能) 固有の手順

これは、因数分解されたコードのグループ化と同時に、それが何であるか、どこにあるか、およびその他について非常に簡単に識別できるようにすることでした。それでも、これらの一般的なクラスを過度に具体的なコードで混乱させることはできません。

これらすべてのクラス間の配線は、Spring によって処理されます (こつをつかむと、すばらしい仕事をするキュウリ スプリングを使用します)。

于 2015-09-10T09:04:48.910 に答える