ユーザストーリーから始めるTDD

     

TDD from starting from user stories - a top-down styleを日本語でザックリまとめました。
意味を明らかに取り違えているようなところがありましたら指摘してください。

TDDのルールは最初にテストを書く事だ。現実世界のプロジェクトの多くは、ソフトウェアがGUI、Web、データベースや外部システムとの依存を含んでいる。大概これらはJUnitクックブックのサンプルほどシンプルではない。プロジェクトが異なれば、TDDの実装方法も異なる。例えばテスターが受け入れテスト記述の責務を取り、開発者はユニットテストを書く。TDDer向けにユーザストーリーから始めるトップダウンなTDDスタイルを提唱したい。

What?
ユーザストーリーに基づいた受け入れテストを書いて、失敗させて、ユニットテストを書いて、失敗させて、修正して、いくつものユニットテストが出来上がったら、もう一度受け入れテストを走らせる。それがパスしたら次の受け入れテストに移行する。これの繰り返し。

このプロセスにはいくつかのポイントがある：

* 受け入れテストとユニットテスト間には、いくつかのレベルの機能テスト（モジュールテストや統合テスト等）が必要となる。
* とにかくシンプルにテストをパスさせる事を心がける。
* 良いユーザストーリーが必要だ。良いユーザストーリーとは小さくてテストしやすい。基準やストーリーが不明瞭だと受け入れテストが書きづらい。ストーリーが大きすぎると時間がかかる。

Why?
TDD狂信者はソフトウェアの全てをテストしたがるし、全てを自動化させたがる。テストは要件を表している。"no test, no code"ルール。要件を表すのにテストファーストを行う事で、プロダクションコードを書く前に必要な機能がハッキリとわかる。テストはまた品質保証にもなり、ドキュメントやリファクタリングの土台等を提供する。

ユニットテストを書く時点で、クラスのテストすべき機能やインターフェースはハッキリとしているだろう。しかし、どのようにして必要なクラスを決めたり設計したりするのか。この答えは、ストーリーに記述されている機能にかなったクラスを作るようにするという事だ。ストーリーに記述された機能の理解に基づいてユニットテストを書く。

つまりストーリーに要件が記述されていないと、コードをどうすればいいのか、何のユニットテストを書けばいいのかが不明瞭になる。ストーリーで表された機能からテストすべきパブリックインターフェースが決まり、テストの失敗を通して解決策を見つけたり、対応するユニットテストを書く。

受け入れテストを書く事から始めるとストーリーの要件を確りと把握出来るようになり、要件を満たすシンプルな解決策を選択できるようになる。各クラスの機能を理解した上でユニットテストを書き、シンプルなコードでテストをパスさせる。これはとても自然なTDDアプローチだ。

How?
まず、受け入れ基準をテストに落とし込むに当たり、最も重要なファクターのひとつはツールを見つける事だ。機能テストツールはこのプロセスにおいてユニットテスティングツールよりも重要である。

Webアプリケーションであれば、Selenium、Watir、Sahi。JavaGUIアプリケーションならAbbot、WindowsフォームアプリケーションはNUnitForm、UIAutomation Frameworkは幅が広い。QTPはヘヴィだ。

テストコードの継続的リファクタリングはテストをわかりやすくし、よりビジネスに特化(DSL)させる事が出来る。RBehaveやJBehave等はビジネス価値を明確に反映させ、技術者ではない人間にも理解しやすい受け入れテストを記述出来る。

良い点：

* 受け入れテストを最初に書く事で、開発者はコードを書く前に価値について深く考える
何をテストすべきなのかを明確に判っていないと受け入れテストを書くのは非常に難しい。”テストファースト”ルールを厳密に適用させると、開発者はコードを書く前にビジネス要件について深く考える。これによって要件の誤解を最小限に抑え、発注者と開発チームの食い違いを減少させる。

* テスト自動化をプロジェクト開始時から行いやすい
受け入れテストからTDDを始める事は、プロジェクト内にある全てのテストの自動化を暗に意味する。ビルドやテストの自動化無しで素早いフィードバックを得る事は不可能だ。CruiseControlの様な継続的インテグレーションツールによって回帰テストも行いやすくなる。

* 明確且つシンプルな設計、テスト可能なコード
ストーリーのビジネス価値やテストに反映させる受け入れ基準をちゃんと理解するべきだ。後はシンプルなコードでテストをパスさせる。ユニットテストを最初に書く事でクラスのパブリックインターフェースをシンプルに設計する事が出来るのであれば、機能テストを最初に書く事もまたビジネス価値を実装する為の設計をシンプルに出来る。

* ドキュメントとしてのテスト
TDDによって開発されたプロダクトはドキュメントとしてのテストを提供する。質の高い機能テストは、それを通してビジネス要件と機能の理解を助ける。ユニットテストは各クラスの実装を知る為のドキュメントである。

Testdoxの様なツールは技術者にしか理解出来ないテストコードを技術者では無い人が読みやすいような形式に変換してくれる。RSpec等のテスティングフレームワークにはこの手の変換機能がビルトインされていて、RBehaveやJBehaveはテストそのものがビジネス特化言語で表される。これらはテストがよりビジネス価値を表現しやすく、一目瞭然で、理解しやすくなるようにしてくれる。

* 実装や設計の決定を引き伸ばす
テストをあらかじめ書く事で、実装や設計の決定を最後のステップにする事が出来る。

* プログラミングの良い習慣を助成
開発者はコーディングや技術的な問題のみにフォーカスすべきでは無い。優秀な開発者は本当に価値のある質の高いモノを作り出す為に、全ての物事について深く考える。アジャイル開発方法論は、開発者が多才である事を求める。自分たちのコードを引いた視点で考える事はシンプルな設計をする為の良い習慣を身に付ける手助けとなる。

* テストチームに効果がある
開発者が書き、自動化された機能テストは、テスターにとって非常に効果がある。テスターはパフォーマンステスト、試行錯誤テストや手動テストに時間を費やす事が出来る。彼らは自動化テストが成しえなかったテストに注力できるのだ。

実践的な問題は、冴えたテストコードを生み出せないテスターの存在だ。この問題は開発者がより多くの機能テストを書く事で消滅する。

アジャイル計画では、ストーリーにどのくらい時間がかかるか見積もらないといけない。機能テストを始めに書いた開発者は、全てのテストがパスしたならば、ストーリーを完遂させたと自信を持って言うことが出来る。これによってより正確に見積もりが出せるようになり、リリース計画が立てやすくなるだろう。

* 素早いフィードバック、反復型リリースについては言及しない

悪い点：

* 単純にいかないこともある
TDDスタイルの利点について話してきたが、難しい面も認識しておかないといけない。多くの人にとって、TDD自体がマインドシフトとなる。彼らはコードを書いて、テストして、問題を修正する事に慣れてしまっているだろう。彼らに共通する疑問はコード無しでどうやってテストを書けばいいのかという事だ。TDDやこのアプローチはまず問題を理解する必要がある。TDDを始めるのは簡単では無いが、大切なプラクティスであり、費やした時間には価値がある。

ストーリーによるTDDはいくつかの前提条件を必要とする。まず、良いストーリー。良いストーリーは独立していて、価値があり、見積もりしやすく、小さくてテスト可能だ。良いストーリーは開発者のビジネス価値への理解を容易にし、質問を挙げやすくする。次に、ストーリー毎のハッキリとした受け入れ定義だ。これによって開発者は受け入れ定義をテストに落とし込みやすくなる。良いストーリーはプロジェクト成功の隅石である。

* C++やゲーム、ツールセットの入手が限定される領域では困難
このアプローチの重要なファクターとして優れた機能テストツールの入手を挙げた。常にこの通りにはいかない。使用するプログラミング言語やプラットフォーム、フレームワークによっては入手が非常に困難なこともある。例えばWindowsデスクトップアプリケーションのハンディなテスティングツールは無い。QTPは良いツールだが、TDDには相当ヘヴィだ。他の例としてはゲームがある。CやC++等の言語ではTDDの実装がかなり難しい。

ツールは進化している。数年前はWebアプリケーションの機能テストを行う事は非常に難しかったが、今は結構な数のツールがある。需要は良いツールを作るように人々をドライブする。

* 機能テストの増加に注意を払わない事により、ビルドが遅くなる
機能テストはソフトウェアのあるべき機能をテストする。データベースを叩いたり、ネットワーク越しにデータを転送したり、ファイルの読み書きを機能テスト内でしなければならない事が多い。プロジェクトが大きくなるとこれらの機能テストを走らせる時間が長くなる問題がある。素早いフィードバックを得にくく生産性が落ちてしまう為、開発者がテストを走らせたりテストを書く気がしなくなってしまう。

時々この現実に直面するが、大体解決策が見つかる。例えば、開発中にストーリーに属する機能テストの記述と実行は可能だ。そしてコードをチェックインする前に全てのテストを走らせる。場面によってはテストを小さなグループに切り分け並列で実行する事が出来る。外部システムとのやりとりをスタブとモックを使うように再構成する事も出来るだろう。

それではアイディアとプロセスのデモンストレーションをしよう。Webアプリケーションを開発中で、ログイン機能に関するストーリーがある。これだ：

ユーザとして、朕はWebサイトにログインしたい。すると登録済みユーザ固有の機能が使える。

このストーリーに対して、この様な受け入れ定義がある：

* Happy Path: ログイン成功
Given: ユーザはログインページにアクセスする
When: ユーザは正しいユーザ名とパスワードを入力してsubmitする
Then: ユーザはログインして成功メッセージを見る

* ユーザ名かパスワードが不備
Given: ユーザはログインページにアクセスする
When: ユーザはユーザ名かパスワードを入力せずにsubmitする
Then: ユーザは”ユーザ名かパスワードが入力されていません”というエラーメッセージを見なければいけない

* ユーザ名かパスワードが間違っている
Given: ユーザはログインページにアクセスする
When: ユーザは間違ったユーザ名かパスワードを入力してsubmitする
Then: ユーザは”ユーザ名かパスワードが間違っています”というエラーメッセージを見なければいけない

Ruby on Railsを使ってWebアプリケーションを作るにあたり、seleniumの助けを借りる。このストーリーの受け入れテストを簡単に書けるようになる：

Story "Login", %(
  As a user,
  I want to sign in the website,
  So that I can use registered user specific functionality) do

  @selenium = Selenium::SeleniumDriver.new("localhost", 4444, "*iexplore", 
                                                             "http://localhost", 10000);

  Scenario "user successfully login" do
    Given "correct username and password" do
      @selenium.start
      @selenium.open "http://localhost/users/login"
      @selenium.type "username", "someone"
      @selenium.type "password", "password"
    end

    When "login" do
      @selenium.click "submit"
    end

    Then "user logged in successfully" do
      @selenium.is_text_present "Welcome, someone!"
      @selenium.stop
    end
  end

  #other scenarios...
end

ここでRBehaveを使う。Rubyのコードで受け入れ定義を記述するフレームワークだ。テストを書き終えたら、実行して失敗した事を確認する。それから、どうやってこのテストをパスさせるか考える。この時点で、UsersControllerとloginアクション、Userモデルの作成が必要になるだろう事がわかる。これで決定させて、テストを書き始める：

def test_registered_user_should_able_to_sign_in_and_redirect_to_home_as_default
  post :login, :name => "someone@domain.com", :password => "password"
  assert_equal "Welcome, someone!", flash[:notice]
end

Usersコントローラのloginアクションが、ログイン処理を行いflashにメッセージをセットしているかをテストする。そしてアクションを考えつく：

def login
  user = User.authenticate(params[:name], params[:password])
  flash[:notice] = "Welcome, " + user.nickname + "!"
  redirect_to :controller => "home"
end

もちろん認証はUserモデルに委譲する。その為のテストを書く：

def should_be_able_to_get_authenticated_user
  assert_equal users(:someone), User.authenticate("some user", "user's password")
  ...
end

後はauthenticateメソッドの実装をシンプルなコードで書く。今はHappyPathにフォーカスしているので、例外処理の事は気にしなくても良い。テストをさらに書く事で、コードはより堅牢になっていく。

というわけで、シンプルなストーリーでの成功シナリオの実装プロセスをプレゼンした。問題をいくつもの垂直なスライス（ここでは異なるシナリオ）に切り分けて解決した事に気付いて欲しい。一枚のスライスは、テストを最初に書き、シンプルなコードでテストをパスさせる事でフィニッシュする。こうする事で、各ステップについて大きな自信を持ち、自分たちが作り出している価値をハッキリと認識出来る様になる。

* ツールサポートの欠如
テスティングツールが足りておらず、完全なシナリオの機能テストを記述出来ない事がある。この場面ではアプリケーション全体のテストの代わりにモジュールの機能テストを書く。

* dev unit test -> add functional tests

* 開発者からテスターに機能テスト記述を抜き出す
QAが機能テストを書き、開発者がユニットテストを書く。そして並列に仕事を進めるのは非常に魅力的である。チーム全体の生産性が素晴らしくなるように思える。明確な受け入れ定義があると、開発者はユニットテストを書く事が可能になり、テスターは機能テストを記述出来る。理想的であるが、実践が難しい。このアプローチには次のような潜在的な問題がある：

* 開発者とテスターが並列に作業出来れば、生産性は増加するだろう（が、両者間で頻繁なコミュニケーションが必要になるので疑わしい）
* QAが使うツールによるが、機能テストの記述やメンテナンスをするにあたり、より深いプログラミングスキルを要求する場合がある。QAがそれなりのスキルを持っていないと、開発者が新機能について書いた機能テストを追いかけるのが難しくなる。

この問題が発生した場合、軽減させる方法がいくつかある。ある方法は開発者にいくつかの（全てではない）機能テストの記述とメンテナンスをやらせる（例えばHappyPathテスト）。開発者のビルドと統合して、コミットする前にテストがパスするかを確認する。