web-dev-qa-db-ja.com

野生の良いキュウリの例？

数年前にいくつかのプロジェクトでCucumberを試してみましたが、別の試みをしようとしています。別の「Beginning Cucumber」の記事は本当に必要ありません。代わりに、私は野生での実際の使用をいくつか見たいと思います。他のCucumberユーザーは慣用的でアンチパターンフリーだと考えるでしょう。

だから、あなたの意見では、大規模なプロジェクトで実際のキュウリの仕様の最良の例は何ですか？

rubycucumberbdd
60
AndrewO

diaspora's キュウリのテストを読むことができます。かなり大きなプロジェクトなので、そこから何かを学べると思います。

36
Vasiliy Ermolovich

Cucumber自体の機能を読むことができます。彼らは彼らが何をしているのか知っているはずです。

https://github.com/cucumber/cucumber-Ruby/tree/master/features

17
Michael Kohl

これは直接的な答えではありませんが、質問の前提には同意しませんが、解決策があるので、とにかく意見を述べます。

他のCucumberユーザーは慣用的でアンチパターンフリーだと考えるだろう

この声明は、残念ながら満足することは不可能だと思います。

CollectiveIdeaのBrandon Keepersが あなたは一般的で再利用可能なステップに向けて努力する必要があります という一般的な立場を取っています。

ただし、Cucumberの作者であるAslakHellesøyは、 シナリオ固有のステップに向けて努力する必要があります という一般的な（ただし相互に排他的な）意見を取り入れています。 ？」

上記のリンク「トレーニングホイールが消えました」から、アスラックは2つのスタイルを鋭く対比する2つのシナリオ例を作成しました： 再利用可能なステップ vs シナリオ固有 。

両方のスタイルでキュウリを長年使用し、上記のジレンマを考​​慮して、これらは私の結論です：

  1. 再利用可能なステップは、より複雑なステップ定義をサポートすると同時に、名前の競合を回避する必要があるため、メンテナンスの悪夢になります。
  2. 読みやすく簡単にするためにシナリオ固有の手順をお勧めしますが、名前の競合が原因でメンテナンスの悪夢にもなります。

そのため、Cucumberは現在壊れていると判断しました。お気に入りの単体テストフレームワークの上にある単純なCapybaraが最も柔軟です。

Cucumberは、シナリオコンテキスト、機能固有のシナリオ、シナリオの名前空間などを選択した場合、シナリオごとに（機能、ユーザーロール、意味のあるものごとに）スコープを設定し、名前の競合を大幅に減らしてシナリオ固有の手順を作成できます。本当に実行可能。その時点で、明確な文体的な勝者がいると思います。それまでは、名前の競合を避けるために手順を抽象化する必要があるのではなく、単純化して読みやすくするためにシナリオ固有の手順を維持したいという緊張が常にあります。

これらの欠点に対処しようとする代替プロジェクトは Spinach ですが、プロジェクトはそれほど活発ではありません。 ホウレンソウ対キュウリの評価についての私のコメントはこちら 。

11
Woahdae

キュウリのプロジェクトも探していました。そして実際には、そのようなプロジェクトのリストを含むCucumberのリポジトリにwikiページがあります（すべてのプロジェクトがまだCucumberを使用しているわけではありませんが）：

キュウリを使用したプロジェクト：

出典：https://github.com/cucumber/cucumber/wiki/Projects-Using-Cucumber

8
Kirill Zhukov

私はお勧め：

https://github.com/teambox/teambox/tree/dev/features

更新：Ivailo Bardarovが述べたように、彼らはWebstepsを使用していますが、これは現在のところ悪い習慣です。これを参考にして、手順ではなく優れた機能を確認してください！

アップデート2：遅れていると思う、Rails book。のソース版のObject。の有料版で提供されている以下のキュウリ機能から多くを学んだ。ソースコードはオープンソースではないのでここに投稿できない。またはそれへのリンクが見つかりませんでした。

私の好ましい方法は、特定の手順やフォームに記入するのではなく、機能言語をドメイン/ビジネス言語に近づけることです。だから私の機能でこのようなものを持っている代わりに：

When I fill in "Name" with "XYZ

私の機能を言うようになります：

When I create a project:
| name |
| xyz  |

そして、私のステップは、リンクをクリックし、テーブルを解析し、関連するフォームフィールドに入力するコードなどを持っているでしょう.

6
Chandresh Pant

現在のプロジェクトでCucumberを使用してWebアプリの再設計を行っていますが、それはオープンソースではないため、実際の機能と手順のセットを提供することはできません。

これらの twosamples のページオブジェクトパターンに大きな影響を受けていると思います。私たちは、UXチームによるUIリファクタリングの最中です。ページオブジェクトを使用すると、テストをそれらの変更に適度に簡単に適合させることができます。

3
Mike Cornell

企業リポジトリ（Fortune 500向けの大規模な内部Webアプリ）からのものを投稿できたらと思います。

おそらく、ウィキペディアのテストが最高です：

https://github.com/wikimedia/qa-browsertests

あなたは本当にページオブジェクトを抽象化する必要があります。それでも、アプリが30画面を超える入力を取得すると、テストを抽象化するのが難しくなります。

サイクルなしで一般的なパスをすばやく抽象化する実験的な方法があります。おそらくクリーンアップし、プルリクエストとしてCheezyに送信する必要があります。 https://github.com/cheezy/page-object

3
Chad Brewbaker

大規模プロジェクトの一般的な問題は、Cucumberの機能の作成に時間がかかることです。

そのため、いくつかの戦略が関係します。Cucumberを使用してレガシーシステムを記述する場合、きゅうりとcapybaraを介して適切な受け入れテストカバレッジを取得し、キュウリのステップ定義をリファクタリングします。

ユニットテストが適切に行われている場合は、Cucumberを使用して、アプリのハッピーパスのみ、または不可欠なハッピーでないパスのみを記述します。 RSpec（または任意のXunit）でカバレッジを取得します。

Cucumberの重要な問題は、機能が非常に高いレベルで機能を記述する必要があることです。ステップ定義をDRYおよび再利用可能にする必要があります。私は、ステップ定義をリダイレクトして、利害関係者の関心のある機能を簡潔かつ要点に保つのが好きです。少し議論があります。

2
Richard Conroy