問題タブ [gherkin]

Railsコミュニティでの統合テストの主流であるため、gherkhinでキュウリを使用しています。しかし今、私はそれが銀の弾丸であるとは思えません。

キュウリを使用する必要がある場合がいくつかあります。

1. プログラミングの知識がなくても、誰かに機能を見せてもらう必要があります。たとえば、クライアントへ。
2. キュウリ自体がレリッシュの助けを借りて行うように、その場でドキュメントを作成したいのですが、お金を払う必要はありません。公開ドキュメントで必要とされるオープンソースプロジェクトには非常に優れていますが、クローズドプロジェクトや小規模プロジェクトにはそれほど優れていません。

あなたがプログラマーであり、統合テストで製品をカバーしたいだけの場合、キュウリを使用する他の理由はありますか？または、BDDを使用したいが、将来のアプリについての詩をガーキン言語で書きたくない場合はどうでしょうか。

ステップの1つが失敗した場合でも、Cucumberステップの実行を継続する方法はありますか。私の現在のセットアップでは、ステップが失敗すると、キュウリは残りのステップをスキップします....キュウリランナーのセットアップをひねる方法があるかどうか疑問に思います。

失敗したステップをコメントアウトすることはできますが、どのステップが失敗するかわからない場合は実用的ではありません...残りのステップを続行できれば、失敗したテストの完全なセットを1回のショットで知ることができます....サイクルを繰り返すのではなく..。。

環境：Cucumber JVM、R、Java、Ibatis、Spring Framework、Maven

これは私が遭遇した興味深いトピックであり、私の同僚と私はこの問題について異なる意見を持っています. Gherkin は、テストが何を行っているかを正確に説明する必要があります。または、テストで達成しようとしたビジネス ロジックのみを表示する必要があります。

私が職場でよく遭遇する最大の例は、アイテム A にアクセスできる場合は、A にアクセスできるはずだということです。A にアクセスできるユーザーには 20 種類のユーザーがいる可能性があるため、1 つだけを選択します (テスト スイートの実行に 40 時間もかからないようにするためです)。では、どちらが「より良い」でしょうか？

あ

またはB

与えられたステートメントの違いに注意してください (タイプ 4 ユーザー)

ステップ定義では、テストにタイプ 4 のユーザーを使用する予定ですが、テストはタイプ 4 のユーザーに固有のものではありません。アイテム A を持つすべてのユーザーがこのテストで機能します。ログインにユーザー タイプが必要なため、タイプ 4 のユーザーを使用しています。

したがって、A はテストの内容を説明します (アイテム A へのアクセス権を持つタイプ 4 ユーザーでログイン)

B は、アイテム A にアクセスするために必要な機能を説明します (アイテム A にアクセスできるユーザーのみ)。

質問する前に、アイテム A へのアクセス権を持つユーザーを特定する方法は、ユーザーにリンクされた特定のアイテムを検索するデータベースへの SQL 呼び出しです。

Capybara + Webkit + Ruby 1.9.3では、次のHTMLがあります

simple_formは、特定のフィールドでエラーが発生した場合に以下を生成します。エラーテキストスパンを「取得」するのに問題があり、エラーが発生している可能性のある別のフィールドではなく、「タイトル」に関連付けられているスパンがあることを確認しています。

（もちろん、他の多くの分野も！）

タイトルが実際に必要であり、ユーザーが空白のままにして送信ボタンをクリックすると、「空白にすることはできません」というエラーメッセージが表示されることをテストしたいと思います。simple_formを微調整して全体をラップする以外に、ラベルを見つけてDOMの次の要素に移動し、そのスパンが「空白にできない」コンテンツであるかどうかを確認する方法はありますか？

インテリセンスは、アセンブリ参照からの Gherkin ステートメントをリストしません

例: プロジェクト A の「Specific.feature」

プロジェクト B - プロジェクト参照 "Commons.feature" として A に含まれる "<element>" をクリックすると

「Specific.feature」ファイルで、インテリセンスを実行すると表示されません [「<要素>」をクリックします]

-前もって感謝します

cucumber を学ぶために railstutorial.org をフォローしていると、テスト プログラムがクラッシュし続けます。

「bundle exec cucumber features/」と入力して、signing_in.feature を実行すると、コマンド ラインに次のようなメッセージが表示されます。

スタックレベルが深すぎる (SystemStackError) C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1.gems/cucumber-1.2.4/lib/cucumber/parser/gherkin_builder.rb:100

以下は、私の gemfile からコピーされます。

Gherkin でシナリオを定義する場合、Given ステップと When ステップの間に明確な区別がない場合があります。つまり、ユーザーからのシステムとのアクティブな対話はなく、検証の目的は、特定の状況下でシステムがどのように見えるかを検証することです。

次の点を考慮してください。

対

常に 2 番目のバリアントを使用するかどうかはわかりません。「ユーザーはアカウントページにいます」というコンテキストを共有する複数のシナリオがあり、そのうちのいくつかには追加のユーザーアクションがあり、他のユーザーには含まれていない場合、「アカウントページのユーザー」を特定のステップとして保持することが有効であるように思われます一部のシナリオでは「いつ」が欠けている場合がありますが。これは有効なアプローチですか？

Cucumber を使用してショッピング カート、BDD を開発しているとします。カートはかなり複雑で、さまざまな機能が備わっていますが、これは「ブログ」や「ユーザー プロファイル」にも当てはまります。

私は常に「カート」を機能と見なし、ベルとホイッスルをシナリオと見なしてきました。ただし、これは大きなFeatureファイルを作成する可能性があり、 Scenarioの文字通りの意味に反します。これがどのように見えるかです：

詳細を記入すればするほど、この「空のカート」グループは長くなります。「カートを空にする」はスタンドアロンの機能と見なすべきでしょうか? これにより、多くのFeatureが発生し、すべてに少数のScenarioが含まれます。その後、シナリオは「コンテキスト」のようになります。そのようです：

何かをFeatureにするための適切なガイドラインは何ですか? シナリオを独自の機能に再グループ化する必要があるのはいつですか? フィーチャーには通常いくつのシナリオがありますか?

登録例を実行しようとしていますが、行き詰まります

次に、次のエラーが表示されます。

[Behat\Gherkin\Exception\ParserException] コメントまたはシナリオまたはアウトラインまたはステップ トークンが必要でしたが、例を取得しました

私は何を間違っていますか？behat docなどでヘルプが見つかりません。