テスト開発（TDD）は、コードの品質と信頼性を向上させる優れた方法です。 同じアプローチを要件の開発に拡張できます。 これは、受け入れテスト開発（ATDD）と呼ばれます。 最初にこのアプローチをよく見てから、それを適用しようとしました。それから、自分のニーズに合わせて長い間調整し、考えを共有したいと思います。 そして、あなた自身のために、もう一度すべてを棚に置いてください。

この記事では、このトピックについて簡単に紹介します。 この例は非常に単純で、説明する可能性が高くなります。 そして次の記事では、実際の製品で実際の機能を開発するときに、実際にATDDを使用した方法の話を共有しようとします。

導入する代わりに

ある銀行のアウトソーシング会社でプログラマーとして働いていたとき、要件の仕様を検討し、タスクの複雑さを評価する必要がありました。 可能な限り正確に評価する必要があり、プロジェクトの支払いモデル（固定価格）に取り組みました。期限内のすべてのミスは私たちの側にあり、支払われませんでした。 仕様書を読むたびに、すべてを理解しましたが、それらに非論理的な瞬間、省略、奇妙さを感じませんでした。 しかし、開発が開始されるとすぐに、要件のすべてのジャムがクロールされ、最初にそれらを逃したのは驚くべきことでした。 あらゆる努力にもかかわらず、実装前に仕様を読んで問題を見つける方法を考えることができませんでした。

それから私は、巨大で複雑な箱入り製品を開発している大企業で働き、そこで大きなチームが働きました。 アナリストはパートナーや顧客と連絡を取り、彼らの願いを書き留めました。 次に、これらの仕様は、実際に使用される前に、開発者が参加するレビュー手順を経ました。 会議自体で時間を無駄にしないために、最初に要件を読み、質問を準備する必要がありました。 前のドラフトと同様に、文書の内容に関する質問のほとんどは、開発中に発生し、いつ発生するか、つまりレビュー段階では発生しませんでした。

それから私は自分のスタートアップに行きました。 当然、アナリスト、仕様、レビューはありませんでした。 電子メールまたは電話の形でユーザーからフィードバックを受け取り、すぐに機能に変換して開発計画に盛り込みました。 文書化された要件はありませんが、タスクの複雑さを評価する必要がありました。 一見非常に単純に見えたが、実際には頭痛になり、その逆もありました。 コンテキストをある問題から別の問題にすばやく切り替えると、既に実装されているソリューションが頭から飛び出し、それらを1つの製品に統合することがますます困難になりました。 何らかの種類の技術文書、テスト計画、要件が必要でした。 そして、安価に。

ATDDとは何ですか？

受け入れテスト駆動開発（ATDD）は、テスト駆動開発（TDD）のアイデアの開発です。 一般的な意味では、何かをする前に、完了した作業の基準と正しく完了した作業の基準を考え出す必要があります。 なぜこれが重要なのですか？ これらの基準により、非常に早い段階で、正確に何を行う必要があるのか​​、どのように行うのか、正確に何が良い結果とみなされるのかを理解することができます。 すなわち 途中で詳細を調べてプロトタイプを作成するのではなく、すぐに目標に近づきます。目標はすでに決定されており、正式に決定されているからです。

これらの基準は、顧客が理解できる言語で既製のスクリプトの形式で記述されます。 シナリオは、設計された機能が将来どのように使用されるかをモデル化します。 シナリオが実装され、実際に期待される結果が得られる場合、問題は正しく解決されており、作業は完了したと見なすことができます。 このようなシナリオのセットは、受け入れテストと呼ばれます。 受け入れテストは、内部構造や実装の技術的な詳細ではなく、人の観点からのシステムの動作に焦点を当てています。

一般的な名前にもかかわらず、このアプローチはプロセスの非常に具体的な部分を指します-要件が仕様で開発され形式化される部分です。 このプロセスでは、人々は多くの場合、ビジネス側と技術側の両方から参加します。 異なる能力と世界観を持つ人々。 直感的なレベルの顧客は、製品で何を見たいかを正確に理解しますが、要件を簡単に（そして完全に）策定およびリストすることはできません。 開発者（エグゼキュータの代表者）は、顧客が正確に何を伝えるのを忘れたか、どのように見つけるかを知らないことがよくあります。

これらの問題を解決するために、Given-When-Thenフレームワークが使用されます。

指定されたフレームワーク-いつ-その後

受け入れテストのポイントは、特定のシナリオでシステムに何が起こるかを示すことです。 これを行うには、テストの開始時にシステムがどのように見えるかを記述し、このシステムを変更するアクションを記述する必要があります。 外部からの影響、または何らかの内部トリガーの可能性があります。 その結果、システムは状態を少し変更します。これが成功の基準です。 重要なポイント：システムはブラックボックスと見なされます。 言い換えると、テストを策定するとき、システムが内部でどのように構築され、外部とどのように相互作用するかがわかりません。 1つの機能があります。 システムの変更が直接観察できない場合があります。 これは、受け入れ自体が機能しないことを意味します。 2つの方法があります-隣接する兆候を介して間接的に状態を判断しようとするか、単にそのようなテストを使用しないかです。 例としては、データベーステーブルのフィールドの変更、アクセスできないファイルの保留中の変更などがあります。

単体テストでは、Arrange-Act-Assert（AAA）テンプレートを使用します。 これは、テストでは、データの準備を担当する明示的な部分が存在する必要があることを意味します-アレンジ、アクション自体、結果を確認する必要があります-行動し、実際に現実が期待と一致することを確認します-アサートします。 受け入れテストでは、Given-When-Then（GWT）アプローチが使用されます。 本質は同じですが、異なる角度からのみです。

• 「与えられた」もの、すなわち 初期時のシステムの状態
• トリガーを直接設定すると、結果につながるはずです。 ほとんどの場合、これは何らかのユーザーアクションです。
• 次に、このアクションの結果、つまり 受け入れ基準です。

特定の部分には、1つの状態と一連の状態の両方を含めることができます。 複数ある場合、これらの状態は「AND」を介して読み取られる必要があります。 「OR」を介していくつかの状態を結合することは可能ですが、それでは2つの異なるテストになります。 これにより、録音を簡素化できます。 状態のすべての可能な組み合わせが記述されるまで、これを避けることをお勧めします。 そうすれば、何も忘れられないことを確認し、いくつかのテストを1つにマージして、読みやすく理解しやすくします。 同じことがThenにも当てはまります-確認する必要があるいくつかの結果があるかもしれません。 いつでなければなりません。 トリガー干渉を避けることが最善です。

GWTテストは声を出して読むことができます：「AとB、Cを（与えられた）させます。（いつ）Dになったら、（その後）EとFになります。」 これらは、文書化または要件の定式化に使用できます。 読んだと言っても、そのように書かなければならないという意味ではありません。 実際には、このようなテストは非常に大規模です。 それらをプレーンテキストで書き留めた場合、それらを体系的に見ることは非常に困難です。 システムがなければ、重要なスクリプトは簡単にスキップできます。

非常に重要なポイント：作業に最適な記録形式を選択する必要があり、作業がより便利になります。 ここに制限はありません。 与えられたとき、それは-これがレコードの一般的な構造、つまり、テストに含まれる必要のあるものであり、直接的な表現は何でもかまいません-少なくとも文章、少なくとも表、さらには図です。

ATDDは規則を指示するものではありませんが、例を通して仕様をコンパイルするためのフレームワークを提供します。 ブラックボックスモデル、GWT、およびそれらの組み合わせがあります。 他のすべては、実際にはこれらのメカニズムの適用であり、その一部は確立されていると見なすことができます。

例

たとえば、信号機など、シンプルでわかりやすいものを取り上げます。 GWT表記を使用して信号機の開発要件を説明するにはどうすればよいですか？ まず、信号機の中でギブンと呼ばれるものを正確に把握する必要があります。

信号機の状態については、現在どのセクションにあるかに関する情報を取得できます。 信号機は、一定の間隔で切り替わります（状態を変更します）。 したがって、トリガーはタイマー、またはむしろタイマーです。 トリガーの結果は、いずれかの状態への遷移です。 すなわち この例では、GiveとThenの信号を使用して、同じセットを想定しています。

1. 赤く点灯
2. 赤と黄色に点灯
3. グリーンオン
4. 緑色の点滅
5. 黄色の光

GWT表記で信号機の動作を説明します。

1. 赤信号をしましょう。 タイマーが作動すると、信号機は赤と黄色の同時モードに切り替わります。
2. 赤と黄色が点灯します。 トリガーが起動すると、信号が緑に切り替わります。
3. 緑色に点灯します。 トリガーが起動すると、信号が緑色の点滅に切り替わります。
4. 緑が点滅します。 トリガーが起動すると、信号が黄色に切り替わります。
5. 黄色のライトを点灯させます。 トリガーが起動すると、信号が赤に切り替わります。

信号機の仕組みを理解できる5つのシナリオを読んでください。 当然、信号機には多数のモードがあります。たとえば、黄色の点滅モード（障害がある場合）、または手動制御モード（たとえば、事故の場合）などです。 しかし、図を複雑にしないようにしましょう。

テストを言葉で説明することは私にとって冗長なようです。 さらに、色の名前のみが変更されます。 ここでは、状態図または単純なテーブルの方が優れています。

	与えられた	いつ	それから
1	赤	タイマー	赤+黄
2	赤+黄	タイマー	緑色
3	緑色	タイマー	緑色の点滅
4	緑色の点滅	タイマー	黄色
5	黄色	タイマー	赤

この例は、受け入れテストの主な利点の1つを示しています。ほとんどの言語でビジネスユーザーと通信できます。 素晴らしいボーナスは、テストとその後の自動化のための既製のスクリプトセットです。

満腹

表記法-いつ-その後、テストをコンパイルするプロセスを構築し、テストがシステムの動作のすべての側面を記述しているという自信を与えます。 座って、常に自問する必要はありません：「そして、まだ説明していないシナリオは？」

したがって、アルゴリズムは次のとおりです。

1. 設定可能なすべての状態を定義します。 すべて与えられた。
2. すべてのトリガー、つまり いつ
3. すべてを定義するそれから、正確に何が起こるか。
4. 次に、これらのリストを組み合わせて乗算する必要があります。
5. 結果は一連のテストです。

これらの各段階では、最終的に何をどのように機能させるべきかを最もよく知っているのは顧客であるため、顧客またはその役割を演じる人の参加が必要です。

なぜ役に立つのか

既に述べたように、同様のアプローチは、冗長性にもかかわらず、どのシナリオもスキップされないという自信を与えます。 これはおそらく、そのような形式化の主な利点です。 多くの場合、ビジネスユーザーはプロセスを一般的な用語でのみ表示し、詳細を表示できません。 「このような機能が必要です。すべてを思いついて、写真を見てください」または「このようなボタンが必要です。すでに同様の機能があります。他のことをしてください。」 開発を開始する前に座って、イベントの開発の可能なオプションを見つけたら、すぐに多くの詳細が表示されます。ご存知のように、そこには悪魔が横たわっています。

同様のアプローチは、指定子がアナリストから来て、それを読む必要がある場合にも役立ちます。複雑さと労力の推定値を与えます。 すべての詳細を読み飛ばすときに、GWTの要約を読み進めていくと、どのシナリオが要件で不十分または不正確に扱われ、説明が必要かがすぐに明らかになります。

要件を分析してソリューションを開発することに加えて、GWTシナリオを使用して要件を収集することもできます。 ある種の機能領域とそれを理解する人がいると仮定しますが、彼と通信する時間は非常に限られています。 事前に準備し、GWTフレームワークを使用してスクリプトを解析する場合、インタビュー自体では、Given、Whenセクションから何も忘れていないことを確認し、Thenセクションの正確な内容を明確にする必要があります。

GWTスクリプトを自動化するための特別なツールもあり、自然言語でも記録されます。 例はキュウリです。 私は彼らと仕事をしなかったので、彼らの存在の事実以外は何も言えません。

落とし穴

GWTのパワーのマイナス面は冗長性です。 与えられたN個のピース​​、いつM個のピース​​、そしてK個のピース​​を定義するとします。 最悪の場合、テストの数は膨大になります-N MK 。そして、なんとかこれで生きる必要があります。 これは複雑さの上限です。 実際には、これらのシナリオのすべてが実行可能であるわけではなく、それらの一部は相互に複製され、優先度が低いか自明であるために別の部分をスキップできます。

2番目の欠点はフォーマットです。 私の経験では、GWTレコードは常にミニマリズムを追求しています。 開発中、多くの場合シナリオは互いに似ているため、詳細な説明に時間を無駄にしたくありません。 結果は読みにくい構造です。 休憩の後、それを理解するには、コンテキストを復元し、条件付きの略語とメモを再度思い出す必要があります。 また、レビューのために誰かにドキュメントを渡す作業も複雑になります。ほとんどの場合、作成者自身がドキュメントを読む必要があるからです。

次の欠点は、ATDDがそれ自体をテストするのではなく、テストシナリオの形式で無料ボーナスを伴う要件の形式化を行う可能性が高い理由を説明しています。 このようなシナリオでは、複合（大規模で複雑な）シナリオを説明できません。 理想的なブラックボックスのテストは、主にその理想性の公理に基づいています。 現実には、箱は黒ではなく、より複雑なシステムの一部である製品である一方で、常に外の何かと相互作用します。 製品内のすべてのリンクを一度に1つのドキュメントに含めようとすると、要件を簡単に再定義できます。 このような一連の受け入れテストは非常に大きく複雑であるため、ほとんど役に立ちません。 したがって、実際には、エンドツーエンドのシナリオは受け入れテストとして使用されません。

少し歴史的背景

ウィキペディアによると、特定のシナリオを介して仕様を策定するというアイデアは、1996年にウォードカニンガムによって最初に説明され 、 マーティンファウラーは2004年に例によって仕様という用語を導入しました 。 アイデアのさらなる発展は、2009年の書籍「Bridgeging the Communication Gap：Specification by Example and Agile Acceptance Testing by Gojko Adzic」で策定されています。 2011年には、このテーマに関する別の書籍「例による仕様：成功したチームが適切なソフトウェアを提供する方法」もリリースしました。 ソースを参照するためにこれらの本をお勧めします。