あなたの上司はTDDを評価しません：この振る舞い駆動開発の例を試してください

テスト。 多くの場合、最後の最後まで残され、時間切れ、予算超過、またはその他の理由でカットされます。

経営陣は、なぜ開発者は「最初から正しく理解する」ことができないのか疑問に思います。また、さまざまな利害関係者がシステムのさまざまな部分を説明する場合、開発者（特に大規模なシステム）は警戒を怠ることがあります。象。

ただし、すべてのプロジェクトの最初のステップは、構築するソフトウェアまたは機能の動作についての議論であることは避けられません。 クライアントまたはビジネスパーソンが開発チームの誰かのところに来て、彼らが何を望んでいるかを説明します。

これらのインタラクションは、アジャイルユーザーストーリーの形で提供される場合があります。 昨年のChrisFoxのブログエントリのように、デザインドキュメントの形で提供されることもあります。 また、Keynoteのフローチャートやモックアップ、または急いで電話をかけることもできます。

これらのコミュニケーションだけから、開発者は「正しく機能する」システムを構築する責任があります。 これは、大規模なシステムの外部で作業するフリーランサーにとっては特に困難です。

なぜテストが削減されるのですか？

ここには明らかなギャップがあります。ビジネスオーナーが最初にシステムの動作を想定している場合、これらの動作が実際に頻繁に機能することをテストするのはなぜですか。

答えはやみくもに単純かもしれません。テストは共有資本とは見なされないことがよくあります。 「彼らはエンジニアのためだけのものである」ため、または同様に、単一の1つの部門または人々のグループに価値を提供するため、プロジェクトに価値があるとは考えられていません。

この共有資本、このシステム動作のリストをどのようにテストしますか？ テスト駆動開発（TDD）だけでなく、ビヘイビア駆動開発（BDD）も採用しています。

BDDとは何ですか？

ビヘイビア駆動開発は、コードが実装しているビジネスビヘイビア、つまりコードの背後にある「理由」に焦点を当てる必要があります。 チーム中心の（特に部門の枠を超えた）ワークフローをサポートします。

アジャイルBDDは、開発者とアジャイル製品の所有者またはビジネスアナリストが一緒に座って、保留中の仕様（後で開発者が記入する）をプレーンテキストエディターで書き込むときに非常にうまく機能することを確認しました。

1. ビジネスパーソンは、システムで見たい動作を指定します。
2. 開発者は、システムの理解に基づいて質問をすると同時に、開発の観点から必要な追加の動作を書き留めます。

理想的には、両方の当事者が現在のシステム動作のリストを参照して、この新機能が既存の機能を破壊するかどうかを確認できます。

この単純な行為によって、開発者のように考えることができる十分な制約が得られることがわかりました。「これらのテストを実装する必要があるとすると、コードで実装できる仕様に私/全員をどのように制約するのでしょうか」。 それらは保留中の仕様であるため、コラボレーションの厚みの中ですばやく簡単に作成できます。

この協調的なアプローチにより、機能がエンドユーザーに提供するものに焦点を当てることができ、ビジネスパーソンがそこにいると、実装ではなく動作について話すことが制限されます。 これは、BDDとTDDの違いを浮き彫りにします。

ビヘイビア駆動開発の例を見てみましょう

シナリオ：あなたは、Railsに実装されている会社の会計システムを担当するチームの開発者です。 ある日、ビジネスパーソンから、保留中の請求書をクライアントに通知するためのリマインダーシステムを実装するように依頼されました。 このtutoriaごとにBDDを練習しているからです。 （TDDに対して）、あなたはそのビジネスパーソンと一緒に座り、行動を定義し始めます。

テキストエディタを開き、ビジネスユーザーが望む動作の保留中の仕様の作成を開始します。

 it "adds a reminder date when an invoice is created" it "sends an email to the invoice's account's primary contact after the reminder date has passed" it "marks that the user has read the email in the invoice"

開発中の動作に焦点を当てているため、コードが正しいことだけでなく、適切な機能を構築していることを確認するためにテストが役立ちます。 言い回しは、システムの内部実装言語ではなく、ビジネス言語であることに注意してください。 開発チームの外部の誰もそれを気にしないので、請求書がアカウントにbelongs_toていることを確認したり気にしたりすることはありません。

一部の開発者は、その場でテストケースを作成し、システムでメソッドを呼び出し、次のように期待値を設定することを好みます。

 it "adds a reminder date when an invoice is created" do current_invoice = create :invoice current_invoice.reminder_date.should == 20.days.from_now end

まだreminder_dateを設定するコードを記述していないため、テストスイートは失敗します。

失敗した仕様に対して

失敗した仕様を書いている開発者は理解していますが、私の側にいるビジネスパーソンのおかげで、これは私にとってはうまくいきませんでした。 間違ったビジネスパーソンは、詳細に気を取られるか、この新しい知識を利用して、開発者がもっと知っていること（適切なデータベース設計、コードの再利用）を細かく管理しようとします。

私の経験では、特定の行動の概要を1行以上書くと、ビジネスパーソンは退屈します。 彼らはそれを彼らの時間の悪い使い方と見なすか、それが彼らの心にある間に次の行動を説明することを切望するでしょう。

BDDはTDDとどのように異なりますか？

テスト駆動開発アプローチを使用して、これを別の方法で見て、保留中のテストを書き出しましょう。

 it "after_create an Invoice sets a reminder date to be creation + 20 business days" it "Account#primary_payment_contact returns the current payment contact or the client project manager" it "InvoiceChecker#mailer finds invoices that are overdue and sends the email"

これらのテストは役に立ちますが、エンジニアという1つのグループの人々にしか役立ちません。 BDDは、部門の枠を超えた製品チームのすべてのメンバーとのコミュニケーションに役立ちます。

保留中の動作を使用することで、BDDの考え方でテストファースト開発を行うことができます。 まず、テストを作成します。 次にそれを実行します（赤）; 次に、それを機能させます（緑）。 次に、それを正しくします（リファクタリング）。

BDDコミュニティでは、テスト内のアサーションチェックを英語のように読み取るために多くの作業が行われています。 ステレオタイプのRSpecテストは次のとおりです。

 a = 42 a.should == 42

この形式により、後で読みやすくなります。 ただし、これはここで行っていることではないことを忘れないでください。重要なのは、動作をできるだけ速くダウンさせ、「仕様ごとに1つのテストされた動作」の原則を適用することです。 理想的には、保留中のスペックタイトルはあなたがテストしているものを教えてくれるはずです。

BDDは、結果を検証するための凝った方法ではありません。 チームのすべてのメンバー間で期待される行動を共有することです。

ビヘイビア駆動開発は、コラボレーションとコミュニケーションに関するものです

私たちのシナリオに戻りましょう：会社の会計システムに取り組んでいます。

アイテムの機能をビジネスパーソンと一緒に歩き、システムの内部（オブジェクトが内部でどのように組み合わされているか）を分析し、システムを外部から分析します。

いくつかの条件を考えて、次のシナリオで何が起こるかをビジネスアナリストに尋ねます。

 * What's the default reminder date going to be? How many days before the invoice due date? * Are those business days or just calendar days? * What happens if there's not a primary contact associated with the account?

そして、あなたは答えを得る。 あなたが彼らのペットのアイデアに穴を開けようとしているのではなく、過度に衒学者であるのではないことをビジネスパーソンが理解することが重要です。

このように、ビヘイビア駆動開発は、コラボレーションを支援し、2つの部門間の会話を開始するためのツールです。 また、目的の機能の範囲を明確にし、開発チームからより適切な見積もりを取得する方法でもあります。 おそらく、特定の時点から10営業日を計算する方法がないことに気付いたでしょう。 これは、実装する必要のある追加の個別の機能です。

開発者には開発者向けの考慮事項（「「日」とはどういう意味ですか？」）があり、ビジネスマンには独自の考慮事項があります（「ここでは期限切れという用語を使用しないでください。これは別の意味です」）。 どちらかのグループを立ち上げて、これらのビジネスロジックの動作テストを自分で作成しようとすると（Cucumberの約束）、それぞれの側の貴重な入力が失われます。

また、アジャイルクライアントが物理的に部屋にいない場合の良い代役にもなります。つまり、作成しているものの開発者分析（および翻訳）と組み合わせて、紙に彼らの欲求を持たせることです。

設計図書

以前のToptalブログの投稿であるChrisFoxは、特にプロジェクトの開始時に、設計ドキュメントについて語っています。 ビジネスの振る舞いを理解して抽出することは、システムがある程度理解できるプロジェクトから、達成するのに数十年のプログラマー年を必要とし、数百または数千の振る舞いの仕様を持つプロジェクトにスケールダウンします。

クリスの記事では、要素の画面上の動作についても言及しています。これは、私が常にデザイナーと対立している領域です。「このボタンは、薄暗いときにどのように見えるか」または「11の画面ではどのように見えるか」という理由で。このページは明らかに24インチの画面用に設計されていますか？」 このようにビジネスパーソンと行ったり来たりすると、プロジェクトのグラフィックアセットやページのレイアウトにギャップが生じる可能性があります。

非常に大規模なクロスファンクショナルチームには、デザイナー、開発者、場合によっては運用担当者、データベース管理者、おそらくQA担当者（はい、TDDとBDDの全員のための場所があります！）など、独自の懸念を持つ多くのチームメンバーがいます。彼ら自身の懸念と質問で。 BDDは、テスト駆動開発よりもこのコラボレーションを推進できます。 「このテーブルに対してデータが大きすぎるとどうなりますか？」から「うーん、それは高価なクエリになります。どういうわけかそれをキャッシュしたいと思います」、「待って、ユーザーはその機密情報をすべて見る必要がありますか？」、開発者だけでなく、この新機能について質問があるビジネスアナリスト

ビヘイビア駆動開発は、共有アーティファクトに関するものです

共有アーティファクトとは何ですか？

私は、ソフトウェアエンジニアリングの「アーティファクト」を、プロジェクトまたはプロジェクトチームを説明する潜在的に物理的なものであり、6か月後に発見できるものと考えるのが好きです。 優れたアーティファクトは、物事がそのようになっている理由を説明しています。

廊下での会話はアーティファクトではありません。 ホワイトボードの図面もありません。 大きな長いクラスのドキュメントまたは設計ドキュメントに変換されるホワイトボードの図面—これらはアーティファクトです。 会議の議事録もアーティファクトです。

アーティファクトは、リポジトリまたは共有スペースに保存されたソースコード、チケットシステムのチケット、内部Wikiのメモ、または永続的なチャットログです。

共有アーティファクトは、私の考えでは、最高のアーティファクトです。 それらは、なぜ何かがそのようになっているのかだけでなく、なぜそれがアプリに存在するのかを示しています。

それらをBDDでどのように使用しますか？

振る舞いは共有チームアーティファクトである必要があります—テストは忙しいだけではありません-プログラマーのために働いてください！ チーム全体が現在の仕様を簡単に表示できるシステムを用意するのが最善ですが（おそらく、展開システムは動作のリストを抽出してサイトのプライベートエリアまたはWikiに保存します）、手動で行うこともできます。スプリント。

ゲームの名前は、「開発者がビジネス価値をより迅速に提供し、部門間で協力し、より適切な見積もりを行うために必要な仕様を作成するのを支援する」です。

システムが何をするかについてのこの全社的な理解は、資本の一形態でもあります。 これは、コードの「方法」に対する「理由」です。

結論

バグのあるソフトウェアが顧客に配信される問題をどのように解決しますか？ テストが「開発者だけが気にする」ものと見なされないようにすることによって。

システムのニーズを説明して理解することには、コードの正確さを超えた多くの利点があります。部門間の対話を確立し、すべての利害関係者の懸念が満たされていることを確認します（大きな豪華なタイトルを持つ利害関係者だけではありません）。 ビヘイビア駆動開発を使用してこれらのニーズを最初から理解し、チーム全体が関心を持っている外部のビジネス行動をテストします。これは、質の高いプロジェクトを確保するための優れた方法です。