フューチャースペックという外からテストを書き始めるテスト駆動開発について

下記の本で、テストは外から、つまりフィーチャースペックから作るといいことを知りました。そこでその手順について質問があります。
Everyday Rails… Aaron Sumner 著 et al. [Leanpub PDF/iPad/Kindle]

次のようなフィーチャースペックを作成した場合は、どのような手順で進めるのでしょうか？
ソースコードの下に私が認識している手順を記述します。

ruby
1# spec/features/users_spec.rb
2require 'rails_helper'
3
4feature 'User management' do
5  scenario "adds a new user", js: true do
6    admin = create(:admin)
7    sign_in admin
8
9    visit root_path
10    expect{
11      click_link 'Users'
12      click_link 'New User'
13      fill_in 'Email', with: 'newuser@example.com'
14      find('#password').fill_in 'Password', with: 'secret123'
15      find('#password_confirmation').fill_in 'Password confirmation',
16        with: 'secret123'
17      click_button 'Create User'
18    }.to change(User, :count).by(1)
19    expect(current_path).to eq users_path
20    expect(page).to have_content 'New user created'
21    within 'h1' do
22      expect(page).to have_content 'Users'
23    end
24    expect(page).to have_content 'newuser@example.com'
25  end
26end

rails newでプロジェクトの作成
spec/features/users_spec.rbの作成
管理者が新規ユーザーを作成するシナリオを記述する
rspecでテストを走らせるとadmin = create(:admin)で失敗
adminファクトリを作成する

ruby
1# spec/factories/users.rb
2require 'faker'
3
4FactoryGirl.define do
5  factory :user do
6    email { Faker::Internet.email }
7    password 'secret'
8    password_confirmation { password }
9
10    factory :admin do
11      admin true
12    end
13  end
14end

userモデルを作成する

** 疑問**
この時、userモデルのテストを作り、userモデルのバリデートやメソッドを作りこんでいくのでしょうか？それとも、spec/features/users_spec.rbに戻り、次は未実装のマクロsign_inを実装して、フィーチャーテストを進めていくのでしょうか？

外からテストを作成していくと、いつモデルやコントローラを作りこんでいくかがわかりません。フィーチャースペックというのがユーザーの正常・異常操作を全て記述するものなら、その都度モデルやコントローラに機能追加をすると思うのですが、どうでしょうか？

それとも先にビュー、モデル、コントローラをある程度用意してから、テストを書き始めるのテスト駆動開発なのでしょうか？違うと思いますが、念のため確認したいです。

ご回答、よろしくお願い致します。

行動規範の内容に同意します

回答1件

テスト駆動開発の基本は、「必要になった時に作る」です。なので、この段階ではUserモデルのテストをするためのspecファイルは作成しても、バリデーションなどの処理はこの段階では作成しません。

一番最初に作るフィーチャースペックとしては、これでも大きすぎます。私なら、まずはAdminとしてログインできるスペックから書きます。たぶん、sign_inした後にsessionのユーザーがAdminかどうかで検証するSpecを書くでしょう。

さて、「どの段階でコントローラーやモデルのテストを書くか」ですが、それもコントローラーやモデルに機能が追加されるタイミングでSpecを定義し、実装するという流れです。この段階でUserモデルにemailやpasswordフィールドを定義しているのであれば、UserSpecでそれぞれの属性を持つか検証するテストは書いておくとおもいます。厳密なTDDでは「テストが失敗するまで新しいプロダクトコードを書いてはならない」という流れだったりします。なので、Userをscaffoldした段階でUserSpecを作るのは本当は遅いですが、厳密すぎるのでそれは脇においても大丈夫です。

まとめると、

フィーチャースペックを書き、そのWebアプリケーションが持つ機能を定義する
必要に応じコントローラーやモデルを生成し、フィーチャースペックを実現するために必要なスペックをそれぞれ定義する
コントローラーやモデルを実装する
必要であればリファクタリングする
機能が完成し、次にスペックに進めるのであれば1.に戻る

1->5の回転がTDDの大きな回転、2->3->4->の回転がTDDの小さな回転でしょう。WEB+DB Pressの昔の記事にそういった内容の記事をt-wadaさんこと和田卓人さんが書かれていました。また、実践Cucumberという書籍もあるので、そちらも参照されるといいかもしれません。(が、元々読まれている書籍にもその辺り書かれていそうなきもします。)

投稿2015/09/03 05:27