Henrik Knibergの記事「ATDD from Trenches」の翻訳（ATDD with Advanced）

オリジナル： www.infoq.com/articles/atdd-from-the-trenches

高度なATDD

初心者向けの受け入れテストによる開発

この状況にあったことがある場合：

次に、この記事は、レガシーコードを使用した既存のプロジェクトで受け入れテスト（受け入れテスト駆動型開発）を介して開発を開始する方法の具体例です。 それは技術的負債の問題を解決する 1つの方法を説明します。
これは実際のプロジェクトの例であり、すべての欠陥と欠点がありますが、本の洗練された演習ではありません。 それで、ベレー帽を着用してください。 派手なサードパーティライブラリ（通常は悪用されることなく）なしで、JavaとJUnitを使用します。
警告：これが唯一の正しい方法であると主張しているのではなく、他にも多くのATDD「スタイル」があります。 また、この記事では、新しく革新的で実績のあるアプローチや経験についてはあまり触れておらず、ここでは直接説明します。

やりたかったこと

数日前、 webwhiteboard.comのパスワード保護を開始しました （私のプロジェクトは趣味です）。 ユーザーは長い間、仮想ホワイトボードをパスワードで保護する機能を追加することを求めてきたので、今こそそれを行うときです。
言葉では簡単に聞こえますが、実際には、設計にかなりの数の変更を加える必要があります。 これまで、webwhiteboards.comはユーザー名やパスワードなしで匿名ユーザーによって使用されていると想定されてきました。 ボードをパスワードで保護できるのは誰ですか？ 誰が彼女にアクセスできますか？ パスワードを忘れたらどうなりますか？ シンプルでありながら、かなり信頼できる方法でこれを実装する方法は？
webwhiteboardコードは、単体テストと統合テストで十分にカバーされています。
ただし、受け入れテスト、つまりエンドユーザーの観点からすべてのレイヤーを通過するテストは完全に存在しません。

デザインを検討する

webwhiteboardの設計の主な目標はシンプルです。パスワードを入力する必要性を最小限に抑え、アカウントを作成するのではなく、他の刺激物を減らすことです。 そこで、パスワードで保護されたボードに2つの制限を設定しました。

• 匿名ユーザーは、ボードをパスワードで保護できません。 しかし、彼はすでに保護されたボードを開くことができます。 彼はシステムに入る必要はなく、保護されたボードのパスワードを入力するだけです。
• ログインとパスワードは、元々Googleが意図した外部OpenId / Oauthコンポーネントによって管理されます。 したがって、ユーザーは別のアカウントを作成する必要はありません。

実装アプローチ

多くの不確実性があります。 実装方法は言うまでもなく、これがどのように機能するかは知りませんでした。 ここに私がやろうと決めたものがあります（ATDD自体）：

• ステップ1.提案されたプロセスを文書化します。
• ステップ2.スタートアップ受け入れテストに変換します
• ステップ3.受け入れテストを実行し、落ちたことを確認します
• ステップ4.受け入れテストの修復
• ステップ5.コードをきれいにする

これらの手順は何度も繰り返されます。 各ステップで、前のステップに戻る必要があります（これはかなり頻繁に行いました）。

ステップ1：提案されたプロセスを文書化する

機能が準備ができていると想像してください。 まるで天使が天から降りてきて、私が寝ている間にあらゆることをしたかのように。 本当であるには余りにも良い音！ 作業が既に行われたことを確認するにはどうすればよいですか？ 最初に確認するシナリオはどれですか？ これを入手しましょう：

1. 新しいボードを作成しています
2. パスワードを設定します
3. ジョーがボードを開こうとしています。システムはパスワードを要求します
4. ジョーが間違ったパスワードを入力し、アクセスが拒否されました
5. ジョーは再試行し、正しいパスワードを入力してアクセスします。 （「ジョー」は私だけであり、別のブラウザからのものであることを理解する必要があります）。

この短いテストスクリプトを書いた後、考慮する必要がある代替シナリオが他にもたくさんあることに気付きました。 しかし、これが主なシナリオであり、機能させることができれば、大きな一歩を踏み出すことになります。

ステップ2：起動受け入れテストに変換する

それほど単純ではありません。 他の受け入れテストはありませんので、どこから始めますか？ 新しい機能は、認証を担当する外部コンポーネントと対話します（最初はJanrainを使用することにしました）。 また、データベースと、ポップアップダイアログ、トークン、ページトランジションなどを含む複雑なWebスタッフが多数存在します。 うわ
後戻りする時です。 「受け入れテストの書き方」の問題を解決する前に、「既存のコードで受け入れテストを書く方法」のより単純な問題を解決する必要がありますか？
この質問に答えるために、最初にシステムに既に存在するシナリオの「最も単純なシナリオ」のテストを作成します。

ステップ2.1最も簡単な自動受け入れテストを作成する

私が始めたスクリプトは次のとおりです。

1. 存在しないボードを開いてみてください
2. 彼女が見えないことを確認してください

そのようなテストを書く方法は？ どのフレームワークで？ どんなツール？ ユーザーインターフェイスを使用してテストする必要がありますか？ テストにクライアントコードを含めるか、サービスを直接呼び出す必要がありますか？
たくさんの質問。 トリック：それらに答えないでください！ すべてがすでに魔法のように行われていることをふりをして、擬似コードのテストを書くだけです。 例：

public class AcceptanceTest { @Test public void openWhiteboardThatDoesntExist() { //1.     //2. ,       } } 

私はそれを起動し、合格しました！ やった！ ええと、でも待ってください、これは間違っています！ TDD三角形の最初のステップ（「赤-緑-リファクタリング」）は赤です。 そのため、この要件がまだ実装されていないことを証明するために、まずテストをフォールさせる必要があります。

おそらく、実際のコードを書くことから始めましょう。 それでも、擬似コードは正しい方向への一歩を踏み出すのに役立ちました。

ステップ2.2最も簡単な自動受け入れテストを赤にする

これを行うために、AcceptanceTestClientクラスを思い付き、すべての問題を魔法のように解決し、受け入れテストを実行するための優れた高レベルのインターフェイスを提供するふりをしました。 使い方は次のとおりです。
client.openWhiteboard（ "xyz"）;
assertFalse（client.hasWhiteboard（））;
このコードを書いたら、テストスクリプトに最適なインターフェイスを実際に思いつきました。 テストには、擬似コードにあったのとほぼ同じ数のコード行が必要です。
次に、Eclipseホットキーを使用して、空のAcceptanceTestClientクラスと必要なメソッドを自動的に生成しました。

 public class AcceptanceTestClient { public void openWhiteboard(String string) { // TODO Auto-generated method stub } public boolean hasWhiteboard() { // TODO Auto-generated method stub return false; } } 

テストクラスは次のようになります。

 public class AcceptanceTest { AcceptanceTestClient client; @Test public void openWhiteboardThatDoesntExist() { //1.     client.openWhiteboard("xyz"); //2. ,       assertFalse(client.hasWhiteboard()); } } 

テストは開始されますが、クラッシュします（クライアントがnullであるため）。 いいね！
私は何を達成しましたか？ あまり言わないでください。 しかし、これは始まりです。 これで、受け入れテストのヘルパークラスの胚芽-AcceptanceTestClientができました。

ステップ2.3 最も簡単な自動受け入れテストをグリーンにする

次のステップは、受け入れテストを緑にすることです。

今、私ははるかに簡単な問題を解決する必要があります。 認証についても、複数のユーザーについても、そのようなことについても気にする必要はありません。 これらのシナリオのテストは後で追加できます。
AcceptanceTestClientに関しては、その実装はかなり標準的でした-偽の（モック）データベース（このためのコードは既にありました）とメモリ内のwebwhiteboardシステム全体のバージョンを起動します。
これはセットアップがどのように見えるかです：

（画像をクリックすると拡大します）
技術的詳細：Web WhiteboardはGWT（Google Web Toolkit）を使用します。 すべてがJavaで記述されていますが、GWTはクライアントコードを自動的にjavascriptに変換し、RPC（リモートプロシージャコール）呼び出しを魔法のように挿入して、非同期クライアントサーバー相互作用の実装の低レベルの詳細をすべて隠します。
受け入れテストを開始する前に、システムを直接「閉じ」て、すべてのフレームワーク、外部コンポーネント、およびネットワーク相互作用を切り取ります。

（画像をクリックすると拡大します）
そこで、実際のクライアントコードと同じようにwebwhiteboardサービスと通信するAcceptanceTestClientを作成します。 違いはカーテンの後ろに隠れています。

• 実際のクライアントは、GWT環境で実行されるWebホワイトボードサービスインターフェイスと通信します。GWT環境では、呼び出しが自動的にRPCに変換され、サーバーに送信されます。
• 受け入れテストは、WebホワイトボードサービスのWebインターフェイスとも通信しますが、RPCなしでサービスの実装を直接呼び出すため、テストの起動中にGWTは使用されません。

また、AcceptanceTestClientの構成は、実際のmongoデータベース（クラウドNoSQLデータベース）をRAMにデータを保存する偽物に置き換えます。
すべての依存関係をスプーフィングする主な理由は、環境を簡素化し、テストを高速化し、テストがすべてのコンポーネントおよびネットワーク接続から独立してビジネスロジックをカバーすることを確認するためです。
この設定はすべて複雑すぎるように思えるかもしれませんが、実際には、たった3行のコードで構成される1つのinitメソッドにすぎません。

 public class AcceptanceTest { AcceptanceTestClient client; @Before public void initClient() { WhiteboardStorage fakeStorage = new FakeWhiteboardStorage(); WhiteboardService service = new WhiteboardServiceImpl(fakeStorage); client = new AcceptanceTestClient(service); } @Test public void openWhiteboardThatDoesntExist() { client.openWhiteboard("xyz"); assertFalse(client.hasWhiteboard()); } } 

WhiteboardServiceImplは、webwhiteboardサービスの真の実装です。
AcceptanceTestClientコンストラクターがWhiteboardServiceのインスタンス（依存性注入設計パターン）を受け入れるようになりました。 これにより、追加の副次効果が得られます。つまり、構成を気にしません。 同じAcceptanceTestClientクラスを使用して、実際のベースで構成されたWhiteboardServiceのインスタンスを渡すだけで、実際のシステムをテストできます。

 public class AcceptanceTestClient { private final WhiteboardService service; private WhiteboardEnvelope envelope; public AcceptanceTestClient(WhiteboardService service) { this.service = service; } public void openWhiteboard(String whiteboardId) { boolean createIfMissing = false; this.envelope = service.getWhiteboard(whiteboardId, createIfMissing); } public boolean hasWhiteboard() { return envelope != null; } } 

要約すると、AcceptanceTestClientは実際のwebwhiteboard Webクライアントのように動作すると同時に、受け入れテスト用の高レベルのインターフェイスを提供します。
「直接呼び出すことができるWhiteboardServiceが既にあるのに、なぜAcceptanceTestClientが必要なのか」と尋ねることができます。 これには2つの理由があります。

• WhiteboardServiceサービスインターフェイスは低レベルです。 AcceptanceTestClientは、受け入れテストに必要なメソッドを、テストをできるだけ明確にする形式で正確に提供します。
• AcceptanceTestClientは、テストに重要ではないあらゆる種類の小さなことを隠します-たとえば、WhiteboardEnvelopeの概念、ブール型createIfMissing、およびその他の低レベルの詳細。 実際、このスクリプトはUserServiceやWhiteboardSyncServiceなどの他のサービスを使用します。

この記事はwebwhiteboardデバイスに関するものではないため、AcceptanceTestClient実装の詳細についてはもう説明しません。 AcceptanceTestClientは、受け入れテストのニーズと、サービスインターフェイスとの対話の実装の低レベルの詳細を結び付けていると言えば十分です。 実際のクライアントコードは、サービスとの対話方法のヒントとなるため、簡単に記述できました。
いずれにせよ、今では最も簡単な受け入れテストに合格しています！

 @Test public void openWhiteboardThatDoesntExist() { myClient.openWhiteboard("xyz"); assertFalse(myClient.hasWhiteboard()); } 

次のステップは少し整理することです。

実際、私はまだこのコードが1行も書かれていません（この機能は既に存在し、機能しているため）。これはテストフレームワークのコードに過ぎません。 それにもかかわらず、私はそれをクリーンアップし、重複を取り除き、メソッドによりわかりやすい名前を付けるなど、数分を費やしました。
最後に、完全性のために、また簡単だったので、別のテストを追加しました：o）

 @Test public void createNewWhiteboard() { client.createNewWhiteboard(); assertTrue(client.hasWhiteboard()); } 

ほら、テストフレームワークがあります！ そして、ファッショナブルなサードパーティライブラリはありません。 JavaとJunitのみ。

ステップ2.4パスワード保護の受け入れテストを書く

次に、パスワードテストを追加します。
擬似コードを使用して、テストの「仕様」を説明することから始めます。

 @Test public void passwordProtect() { //1.     //2.     //3.     ,     //4.          //5.   ,       } 

そして今、以前と同様に、AcceptanceTestClientクラスに必要なものがすべて揃っているふりをして、テストコードを書いています。 この手法は非常に便利です。

 @Test public void passwordProtect() { //1.     myClient.createNewWhiteboard(); String whiteboardId = myClient.getCurrentWhiteboardId(); //2.      myClient.protectWhiteboard("bigsecret"); //3.     ,     try { joesClient.openWhiteboard(whiteboardId); fail("Expected WhiteboardProtectedException"); } catch (WhiteboardProtectedException err) { //  } assertFalse(joesClient.hasWhiteboard()); //4.          try { joesClient.openProtectedWhiteboard(whiteboardId, "wildguess"); fail("Expected WhiteboardProtectedException"); } catch (WhiteboardProtectedException err) { //  } assertFalse(joesClient.hasWhiteboard()); //5.   ,       joesClient.openProtectedWhiteboard(whiteboardId, "bigsecret"); assertTrue(joesClient.hasWhiteboard()); } 

このコードを書くのにほんの数分を費やしました。書いたときに必要なものを思いついたからです。 これらのメソッドは、AcceptanceTestClientクラスにはほとんどありません（まだ）。
コードを書いている間、私はすでにいくつかの決定をしなければなりませんでした。 考えすぎる必要はありません。最初に思いついたことを実行するだけです。 最高のものは善の敵であり、今私が望むのは、十分に良い結果、つまり、実行できて落ちるテストを取得することです。 その後、テストが緑色になったら、コードをリファクタリングし、その設計を改善する方法についてより慎重に考えます。
特にこれらのひどいtry / catchステートメントをリファクタリングするために、すぐにコードを組み合わせ始めたいという誘惑があります。 しかし、TDDの法則の1つは、リファクタリングを開始する前にテストをグリーンにすることです。リファクタリングすると、テストによって保護されます。 そこで、コードのコーミングを延期することにしました。

ステップ3-受け入れテストを実行してフォールする

テストの三角形に続いて、次のステップはテストを開始して失敗させることです。

空のメソッドを作成するために、Eclipseホットキーを再度使用します。 素晴らしい。 テストを実行して、出来上がり、赤だ！

ステップ4：受け入れテストをグリーンにする

次に、製品コードを作成する必要があります。 システムにいくつかの新しいエンティティを追加しています。 追加したコードは非常に重要な場合があるため、単体テストでカバーする必要がありました。 TDDでこれを行いました。 これはATDDと同じですが、小規模です。
これがATDDとTDDの連携方法です。 ATDDを外側のループと考えてください。

（新しい機能のレベルで）受け入れテストを記述する各サイクルに対して、（クラスおよびメソッドのレベルで）ユニットテストを記述するいくつかのサイクルを行います。

そのため、高いレベルでは受け入れテストをグリーン（数時間かかる場合があります）にすることに集中していますが、低いレベルでは、たとえば次のユニットテストであるレッド（これは通常、数分かかります）。
筋金入りの「革張りTDD」ではありません。 「少なくとも、単体テストと製品コードが一緒にチェックされていることを確認してください」に似ています。 そして、そのようなチェックは1時間に数回行われます。 「TDDスタイル」と呼ぶことができます：o）。

ステップ5コードをクリーンアップする

通常、受け入れテストが緑色になったら、クリーニングを実行します。 これを決して節約しないでください！ 食後に皿を洗う方法についてです-すぐにそれをするのが最善です。

私は製品コードだけでなく、テストコードもクリーニングしています。 たとえば、汚いtry-catchをヘルパーメソッドとして強調表示し、クリーンできれいなテストメソッドを取得しました。

 @Test public void passwordProtect() { myClient.createNewWhiteboard(); String whiteboardId = myClient.getCurrentWhiteboardId(); myClient.protectWhiteboard("bigsecret"); assertCantOpenWhiteboard(joesClient, whiteboardId); assertCantOpenWhiteboard(joesClient, whiteboardId, "wildguess"); joesClient.openProtectedWhiteboard(whiteboardId, "bigsecret"); assertTrue(joesClient.hasWhiteboard()); } 

私の目標は、受け入れテストを短く、簡潔で読みやすくして、コメントが冗長になるようにすることです。 最初の擬似コードとコメントはテンプレートとしてのみ機能します-「これは、コードがどれほどきれいであるかです！」 コメントを削除すると勝利感が得られ、ボーナスとしてこの方法はさらに短くなります！

次は？

繰り返します。 最初の動作テストを取得するとすぐに、まだ足りないものについて考えました。 たとえば、冒頭で、ログインしたユーザーのみがパスワードでボードを保護できると言いました。 そこで、これにテストを追加し、赤、緑、そしてコードをきれいにしました。 などなど。
以下は、この機能のために行ったテストの完全なリストです（今のところ）：

• passwordProtectionRequiresAuthentication
• 保護する
• passwordOwnerDoesntHaveToKnowThePassword
• changePassword
• removePassword
• whiteboardPasswordCanOnlyBeChangedByThePersonWhoSetIt

バグを見つけたり、新しい使用シナリオを思いついた場合は、後でいくつかのテストを追加します。
全体として、コーディングには約2日かかりました。 ほとんどの場合、以前に作成したコードとデザインに戻るために費やしましたが、この記事を読んでいるときのように直線的ではありませんでした。

手動テストはどうですか？

もちろん、グリーン受け入れテストを受け取った後、多くの手動テストを行いました。 しかし、自動受け入れテストは基本的な機能と多くの特殊なケースの両方をカバーしているため、より主観的で研究的なテストに集中できます。 全体的なユーザーエクスペリエンスはどうですか？ この一連のアクションには意味がありますか？ わかりやすいですか？ 説明テキストを追加する方が良いでしょうか？ 美的な観点からデザインは良いですか？ デザイン賞を受賞するつもりはありませんが、記念碑的ないものも欲しくありません。
強力な一連の自動受け入れテストにより、退屈な単調な手動テスト（「サルテスト」）が排除され、より興味深く有意義なタイプの手動テストのための時間が解放されます。
理想的には、最初から自動受け入れテストを開始する必要があるため、ある程度技術的な負債を返済しました。

キーポイント

この例がお役に立てば幸いです！ 彼はかなり典型的な状況を示しています-「新しい機能を追加したいので、自動受け入れテストを作成するのはいいことですが、プロジェクトにはまだ受け入れテストがありません。どのフレームワークを使用し、どこから始めるべきかわかりません」。
私はこのテンプレートが大好きで、何度も地面から降りることができました。 要約すると：

1. 本当に便利なヘルパークラス（私の場合はAcceptanceTestClient）にカプセル化された優れたフレームワークを既に持っているふりをします。
2. 現在すでに動作しているもの（たとえば、単にアプリケーションを開くなど）について、非常に簡単な受け入れテストを作成します。 このテストを使用して、AcceptanceTestClientのようなクラスと、関連するテストバインディング（実際のデータベースや他の外部サービスのなりすましなど）を記述します。
3. 新しい機能の受け入れテストを作成します。 実行しますが、クラッシュします。
4. テストを緑色にします。 コードを書くときは、多少複雑なコードの単体テストを書いてください。
5. リファクタリング。 そして、メトリックを改善するために、さらにいくつかの単体テストを作成するか、その逆の場合-不要なテストまたはコードを削除します。 コードを猫の卵と同じくらいきれいにしてください！

これを行うと、最も困難な障壁を克服できます。 ATDDの使用を開始しました！

著者について

Henrik Knibergはストックホルムのクリスプのアジャイル/リーンコンサルタントで、主にSpotifyで働いています。 彼は、人気の著書「 Scrum and XP from the Trenches 」、「 Kanban and Scrum、両方を最大限に活用する 」で説明されているように、ソフトウェア開発の技術的側面と人間的側面の両方で企業の成功を支援しています。そして「 溝からの傾き 」。

アレキサンダー・アンドロノフ（@ alex4Zero）、アントン・ベヴズィク（@bevzuk）、ドミトリー・パブロフによる翻訳
スマートステップグループ 。