自然言語があいまいな場合、振る舞い駆動型開発はどのように明快さを改善しますか？

私は現在、キュウリのようなBDDテストフレームワークを調査しています。

機能ファイルはシンプルな自然言語で記述されているため、わかりやすさが向上し、明確なビジョンが得られます

しかし、自然言語は、ソフトウェアエンジニアリングで発生する問題のほとんどの原因ではありませんか？

自然言語があいまいであり、それがクライアントの要件の誤解と開発者の理解のために多くのソフトウェアプロジェクトが失敗する理由です。私はここでニッチを取得しません。

はい、テストを小さな単純で実行可能なアクションに分解することは理にかなっており、ある程度の明快さを提供しますが、全体として生産性を向上させますか？

PS：私は専門家ではないので、ここでは意見を述べていません。私はその概念を理解したいだけです。

あなたは正しいです。BDDは、言語のあいまいさの問題を排除しません。他の人が指摘したように、翻訳されるスニペットは適切に定義することによって一致する必要がありますが、これも根本的なあいまいさの問題に対処していません。

この問題を解決しないにもかかわらず、なぜBDDが実際に価値があるのでしょうか。いくつかの理由があり、このリストは確かに完全ではありません。

あいまいさは解決されていません

これは、BDDを支持する理由でも、反対する理由でもありません。しかし、ユーザーストーリーや要件などの他のアプローチと比較すると、すべてのSW開発アプローチは、言語の曖昧さに悩まされています。これらはすべて、何らかの方法で自然言語の定式化から始まるためです。

技術的には、言語のあいまいさの問題はlojbanのような人工言語で解決さ​​れていますが、顧客と開発者はおそらくその言語を知らないでしょう。

ユビキタス言語

BDDは、ユビキタス言語のアイデアと密接に関連しています。すべての顧客、テスター、開発者と一緒にシナリオを指定できるため、BDDは他のアプローチよりも優れています。

すべての要件を書き留める従来の要件エンジニアを検討してください。テスターまたは顧客として、レビューの要件が満載された300ページのドキュメントを取得すると、そこで使用されている用語よりも多くの差し迫った問題が発生します。

ユーザーストーリーはすべての利害関係者も作成に含めるため、その面で少し優れています。ユビキタス言語に関しては、BDDとユーザーストーリーのどちらも優れているとは言えませんが、次の点で大きく異なります。

テスト容易性

BDDの主要な側面は、仕様が実際に（Cucumberなどを介して）実行可能であることです。要件もユーザーストーリーもこの機能を提供しません。私個人としては、それがBDDの主なセールスポイントです。

従来の要件とは対照的です-私たちは、要件エンジニアがテスト可能である必要があることを古くから要件エンジニアに伝えてきました。しかし、どのプロジェクトでも、テスターがどこかに特定の要件をテストする方法がわからないことに気付いた場合に遭遇します。

ユーザーストーリーには、正しく作成されている場合、それを確認するために、初期の作成段階でテスターが含まれています。残念なことに、これは現実の世界と衝突する理論の例であり、テスターがこれまでに見たことのない多くの物語を見てきました。

一方、BDDは自動的に実行可能なテストシナリオを提供します。言い訳も方法もありません（オートメーションレイヤーを完全に無視して、派手な詩のシナリオを書き留めない限り）。

より一般的には、Test Firstはソフトウェア開発のすべての段階で非常に有益な原則であり、BDDは開発の最外層への適用です（ユニットレベルのf.ex. TDDと比較して）。

概要

要約すると、BDDは自然言語のあいまいさの問題からあなたを免れません。ただし、2つの重要なポイントを介してその問題に取り組むのに役立ちます：あいまいさを減らすためにユビキタス言語に焦点を合わせる（完全に排除するわけではありませんが、トンを助ける！）と、実行ファイルを書くように強制する仕様。後者の点は、あいまいさの問題に対処するのに役立ちます。それは、あいまいさが問題として現れ始める点だからです。

何かが「自然言語」で書かれている場合、これは多くのことを意味します。

• これは文字通り英語です。英語は非常にあいまいで不正確な言語であるため、この入力モードはソフトウェア開発のコンテキストでは不十分です。

• これは英語ですが、関連する用語が正確に定義されています。このような言語は、法的文書や数学のテキストで使用されています。

• これは正式な言語ですが、この言語は自然言語の慣習に従って非常に厳密にモデル化されています。これは、すべてのプログラミング言語についてある程度説明しています。正式な言語が英語に近いほど、訓練を受けていない読者にとって理解しやすくなります。この目標を持つプログラミング言語の注目すべき例には、COBOLとSQL select id, name from persons where age > 18があります。これらの言語の欠点は、実際のコードを書くために正式な言語を理解する必要があることです。また、これらの言語はしばしば非常に冗長です。

DDDは、プロジェクトがドメインを記述するためにユビキタス言語を使用することを提案しています。これは基本的にケース2です。自然言語内で正確にコミュニケーションできるように関連用語を定義します。

キュウリ自体がケース3です。通常の英語に非常に近い形で読む意図のある正式な言語です。より正確には、Cucumberは、要件/テストを表現するために使用できる単純な形式言語を定義できるようにするフレームワークです。ここでのポイントは、同じドキュメントが自然言語の要件と自動的に実行可能なテストを表すため、2つは常に同期しているということです。きゅうりのシナリオを読んで、それがすべての仕組みを理解しなくても、要件が正しく表現されていることを確認できます。

キュウリは、自然言語の既知のスニペットに対してドキュメントを照合することで機能します。これらのスニペットは最初に定義する必要があります。Cucumberでシナリオを書くには、利用可能なスニペットを認識する必要があります。ソフトウェアはあなたの心を読みません。これらのスニペットは、考えられる問題の原因でもあります。テキストスニペットの動作を実装すると、コードはスニペットテキストが示すものとは少し異なる場合があります。同じスニペットが何度も使用される場合、これが問題になることはほとんどありません。したがって、キュウリは、条件、アクション、および結果のより小さなセットで構成されるビジネスルールを記述するのに適しています。他のテストフレームワークは、各スニペットが1回または2回だけ使用される場合、たとえば各テストケースの設定が一意であるため、より優れている可能性があります。

@ Raghuram8892、Given / When / Then / Andキーワードの後のテキストは「スニペット」と一致する必要があります。一致しない場合、ステップは未定義または「保留中」として失敗します。そのため、ケース3に完全に該当します。

「英語」に関しては、キュウリとその言語であるガーキンは国際的に使用するために設計されています。コマンドを呼び出して、cucumber --i18n help現在サポートされている言語のリストをcucumber --i18n $CODE表示し、特定の言語コードのキーワードを表示できます。たとえばcucumber --i18n eo、エスペラントのキーワードを示します。