空手では、BAと協力してビジネスシナリオを自動化する方法
空手を使用している間、Webサービスのほとんどの検証を行うことができましたが、空手をSelenium Webドライバーと正常に統合し、Javaクラスを使用してDBアサーションを行うことができました。DBの場合、結果セットを返しました。各行をハッシュマップとして変換することでリストとして、空手はそれをjson配列として取得したため、検証が簡単になりました。QA側のニーズのほとんどは、空手を使用して達成されました。
しかし、今日私たちが紹介したとき、それはより大きなコミュニティに開発リーダーの1人が質問を思いつきました。彼はJBehave、BDD、jsonpath、Java、Webサービスなどの専門家です。また、彼の質問は私たちのコンテキストに基づいて本当に関連性があると感じました。しかし、空手のアプローチは異なり、私たちの知識ではうまくいかないかもしれません。
私たちのコンテキストでは、ビジネス用語を使用してビジネスシナリオを考慮してBAにBDDを作成させる必要があり、QA/Devは後でこれらをスクリプトとして変換できます。 （通常、キュウリ+セレン/安心などを使用して従うアプローチ）。たとえば、その中に機能ファイルと10シナリオがある場合、ビジネス側の人々は空手/または別のステップを見て検証の詳細を理解できません単語のプレーンな英語のテキストは、彼らにとってもう少し自明です。ストーリーレベル自体からプロセスの変更を実装しようとするため、このアプローチが必要です。
あなたの考えを共有していただけませんか？
簡単な答え：空手はBDD用ではありません。
私はここにそれについての詳細なブログ投稿を書きました： はい、空手はtrueBDDではありません
それを注意深く読み、恩恵を受ける人々と共有してください。はい、空手はキュウリからBDD構文を盗みますが、その後は別の方向に進みます。
Java API を介して、舞台裏でキュウリのステップ定義として空手を使用できる場合があります。または、 REST-assured、full power to yo のようなものを使用したい場合。
私の個人的な意見は、しないでください。あなたはこれをするのに時間を無駄にするでしょう：
- 「BAフレンドリー」なGherkinが本当に「わかりやすい英語」であり、適切な抽象化レベルにあることを確認します（誰に尋ねるかによって異なります）。 Cucumberシナリオに「実装固有の」詳細が含まれているかどうかについて endlessdebates に備えてください。
- 実際にBAにGherkinを作成させるか、少なくとも開発チームと協力して作成してもらいます。ちなみに、BDDから得られる最大の値はこのコラボレーションです-not実行可能テストとしての仕様の自動化。ですから、実際にこれを行うことができれば（BAから時間とGherkinの専門知識を得ることができます）、おめでとうございます！ これを実現できるチームは多くありません 。
- もちろん、ガーキンは氷山の一角にすぎません。行く必要があります すべてのステップ定義を書いてください 。 空手とキュウリの違い の概要を説明する空手ドキュメントのこの部分を見たことがあるでしょう。
- 私はstrongの観点から、BDDはAPIテストに対してほとんど（そしておそらく負の）値を持っていません。 UIテスト（人間向け）とAPIテスト（機械向け）の大きな違いは、コーディング先の明確な「契約」があることです。このコントラクトは、BDDが強制する意図的な抽象化ではなく、技術用語（JSON /スキーマ）で最もよく表現されます。 APIのエンドユーザーまたはコンシューマーは、通常別のプログラマーです！はい、 APIを製品として -と考える必要がありますが、BDDは物事を行き過ぎています。特にマイクロサービスに関しては、単純な「CRUD」よりも複雑なことをしているサービスに遭遇することはめったにありません。
- この質問を自問してください-プロジェクトの要件定義フェーズの後、BAが引き続きGherkinを読むことを期待していますか？ BDDは、1行のコードを記述する前に練習することになっていることに注意してください。ガーキンがコラボレーション、共通の理解、例を確立するという目的を果たした場合は、通常の自動テストに変換するだけで、振り返ることはありません。
編集： ここの2番目の例 を見て、Cucumberを使用して単純なユニットまたは統合テストであるはずのものをテストするとどうなるかを確認します。
お役に立てば幸いです:)