前回、私がRSpecを書く場合のやり方についての記事を書きました。
今回はインテグレーションテストについて書きます。

私の場合はController,Viewのテストは基本的には書かず、インテグレーションテストで済ませています。インテグレーションテストフレームワークは、

• Cucumber
• Turnip
• RequestSpec
• FeatureSpec
• Steak

など色々あります。以前はCucumberを使っていたのですが、現在担当しているプロジェクトを始める前に、Cucumberに不満があったので、他のやつを試そうという話になって、Steak, RequestSpec, FeatureSpecを試して、FeatureSpecにしました。Turnipはこれらを検討していた頃は有名でなかったので、試していませんが、うちの会社の他のプロジェクトでは、Cucumberの代わりにTurnipを使うようになっています。

ちなみになんでCucumberをやめたかというと、Cucumberは日本語が書けるけれど、別にプログラマがテストできていればいいということであれば、日本語でテスト内容を書くのは二度手間ではないか？という点があったからです。仕様についてはit(scenario)に日本語で書けるし、ブラウザの操作部分を日本語で書く旨味ってなんだろうか？ということになったときに、『自分たちだけが確認すればいい状況だったらメリットはそこまでないよね』ということで、私の担当しているプロジェクトではFeatureSpecを使ってます。

私がインテグレーションテストを行う場合の環境について

私が書く場合の話なので、ここでもFeatureSpecについて書きます。

ちなみにFeatureSpecは以下のものを使って環境を作ってます。

• RSpec
• FactoryGirl
• Capybara(ヘッドレスブラウザ)
• PhantomJS(ヘッドレスなJavaScriptが使える環境)
• Poltergeist(仮想ブラウザでJavaScriptを操作)
• DatabaseRewinder(データベースの掃除を行う)

Seleniumなど、実際のブラウザを使うようなテストにすると速度が遅くなりすぎるので、ヘッドレスなブラウザを使います。これらを使うためのspec_helper.rbの設定の書き方は、ここでは省略します。リクエストがあったら公開を考えます。

FeatureSpecはRSpecなので、書き方は基本的に普通のRSpecと同じですが、インテグレーションテスト用の書き方が準備されています。

feature

describeと同じ

background

beforeと同じ

scenario

itと同じ

インテグレーションテストの場合はシナリオ単位でテストするから、scenarioというDSLはしっくりきます。

テストをするときに意識するポイント

インテグレーションテストは人間の手でやると無茶苦茶時間がかかるところなので、私はできるだけ多くのパターンを書いておきます。が、モデルのテストと重複するようなものは省略します。実際にユーザーがやりそうな操作を想像して、正常系から徐々に異常系のテストも足していってテストを育てていきましょう。

スローテストになりやすいので注意

ただし、インテグレーションテストはブラウザを経由するため、動作はやはり遅くなります。数秒から十数秒で終わるModelのテストに比べると、かなり違います。データの投入はなるべく最小限、かつ、JavaScriptを使うところと使わないところの見極めが大事になります。JavaScriptを必要としないページの場合はなるべくJavaScriptを使う設定をOnにしないようにします。JavaScriptが使えるようにすると、途端にテストのスピードが落ちるからです。

ログイン処理のテストシナリオを書いてみる

では、ログインを例としてテストを書いてみましょう。

feature 'ログイン処理' do
  background do
    visit new_user_session_path
  end
  context '登録済みユーザーでログインを試みた場合' do
    scenario 'ログインできること'
  end
  context '間違ったパスワードを入力した場合' do
    scenario 'エラーメッセージが表示されること'
  end
end

とりあえず思いついたテストは2つとします。

成功のパターン

まず、ログインできること、のテストを記述します。

backgroundブロックで、ログイン用のユーザーを作っておきました。

context '登録済みユーザーでログインを試みた場合' do
  background do
    FactoryGirl.create :user
  end
  scenario 'ログインできること' do
    fill_in 'user_email',    with: 'patorash@email.com'
    fill_in 'user_password', with: 'password'
    click_button 'ログイン'
    expect(page).to have_content 'ログインしました'
  end
  # 略
end

ログインに成功したときにだけある文章を見つけたら、ログインに成功したこととします。

失敗のパターン

次に、ログインに失敗したときのパターンです。
今度はbackgroundブロックを作っていません。
これはユーザーを保存するとデータベースへのアクセスが発生してテストが遅くなるからです。なるべくDBにデータを入れないように注意しておくと、スローテストになりにくいと思います。

context '間違ったパスワードを入力した場合' do
  scenario 'ログインできないこと'
    fill_in 'user_email',    with: 'patorash@email.com'
    fill_in 'user_password', with: 'password'
    click_button 'ログイン'
    expect(page).to have_no_content 'ログインしました'
    expect(page).to have_content 'メールアドレスかパスワードが違います'
  end
end

ログインしましたというメッセージがないことと、エラーメッセージがでていることを確認しています。

ログイン後の機能をテストする

ログイン後の機能をテストしてみたいと思います。
まずはすごくベタに書いてみます。テストする内容は「ブログの記事一覧を表示」とかにしてみましょう。

feature 'ブログの記事について' do
  background do
    FactoryGirl.create :user
    visit new_user_session_path
    fill_in 'user_email', with: 'patorash@email.com'
    fill_in 'user_password', with: 'password'
    click_button 'ログイン'
    visit articles_path
  end
  context '記事が既に存在する場合' do
    scenario '記事のタイトル一覧が表示されること'
  end
  context '記事が無い場合' do
    scenario 'まだ記事がありませんと表示されること'
  end
end

シナリオはこんな感じだと思います。このシナリオのテストは、適当に書いてもらうとしましょう。ここで何に言及したいかというと、backgroundブロックに書いたログイン処理です。この処理、さっきのテストでも書いていますね？こういうブラウザ上での処理を毎回書いていると、とても大変です。なので、関数にしてしまいましょう。

ログイン処理をテストのスコープ内で関数化する

feature 'ブログの記事について' do

  def create_user_and_login
    FactoryGirl.create :user
    visit new_user_session_path
    fill_in 'user_email', with: 'patorash@email.com'
    fill_in 'user_password', with: 'password'
    click_button 'ログイン'
  end

  background do
    create_user_and_login
    visit articles_path
  end
  # 略
end

関数になったことで、背景でなにをしているのかがわかりやすくなりました。「ユーザー作ってからログインしてるんか、ふむふむ…」という感じですね。このテスト内容のみで使いそうな関数ならば、このfeatureファイル内だけで関数を定義すればいいと思いますが、他のfeatureでも同じような処理を使い回しそうだなと思ったら（とくにこのログイン処理のようなもの）、関数を外部に定義しておきましょう。

feature用の関数を定義する

私の場合、spec/support以下に、テスト用のヘルパーを作っています。用途によっていろいろなヘルパーを作りますが、今回はfeature_helpers.rbを作ってみます。

module FeatureHelpers
  def create_user_and_login
    FactoryGirl.create :user
    visit new_user_session_path
    fill_in 'user_email', with: 'patorash@email.com'
    fill_in 'user_password', with: 'password'
    click_button 'ログイン'
  end
end

このヘルパーはfeatureのテストからだけ呼び出せるように、spec_helperで定義しておきます。

RSpec.configure do |config|
  config.include FeatureHelpers, type: :feature
end

こうすることで、spec/features/ならどこからでもログイン用関数が呼べるようになりました。

feature 'ブログの記事について' do
  background do
    create_user_and_login
    visit articles_path
  end
  # 略
end

Ajaxのテストを行う(JavaScriptを含むテスト)

先ほどのブログの記事のタイトル一覧の表示がAjaxで取得されているとします。ブラウザがJavaScriptを使えない場合、テストが成功しないため、Ajaxのテストを行いたい場合は、テスト内でJavaScriptを有効にします。
JavaScriptを有効にするには、js: trueを設定します。

feature 'ブログの記事について' do
  background do
    create_user_and_login
    visit articles_path
  end
  context '記事が既に存在する場合' do
    scenario '記事のタイトル一覧が表示されること', js: true do
      expect(page).to have_content '初めての投稿です。'
    end
  end
  # 略
end

ちなみにこのjs: trueですが、このテスト内の全てでJavaScriptを使う場合は、以下のようにもできます。

feature 'ブログの記事について', js: true do
  background do
    create_user_and_login
    visit articles_path
  end
  context '記事が既に存在する場合' do
    scenario '記事のタイトル一覧が表示されること' do
      expect(page).to have_content '初めての投稿です。'
    end
  end
  # 略
end

ちなみにdescribe, context毎にも設定可能です。シナリオによってはJavaScriptが要らない場合、できればシナリオ単位で有効にしましょう。JavaScriptをオフにしているテストは高速になりますから、シナリオ単位でJavaScriptを有効にしたほうがテストの速度に違いが出てきます。

入力項目がちょっと違うテストを簡単にする

画面系のテストはなにしろ入力のテストが面倒です。たとえば、ユーザー作成画面で色んなパターンを入力させてみたとしましょう。

feature 'ユーザー管理' do
  background do
    create_user_and_login
    visit users_path
  end
  context 'ユーザー登録で' do
    background do
      click_link '新規作成'
    end
    scenario 'ユーザーを登録できること' do
      fill_in 'user_name', with: 'サンプルユーザー'
      fill_in 'user_email', with: 'sample@email.com'
      fill_in 'user_password', with: 'password'
      fill_in 'user_password_confirmation', with: 'password'
      click_button '登録'
      expect(page).to have_content '登録しました'
    end
    scenario '登録済みのメールアドレスはエラーになること' do
      fill_in 'user_name', with: 'サンプルユーザー'
      fill_in 'user_email', with: 'patorash@email.com' # 登録済みメールアドレス
      fill_in 'user_password', with: 'password'
      fill_in 'user_password_confirmation', with: 'password'
      click_button '登録'
      expect(page).to have_content '既に登録済みです'
    end
    scenario 'パスワードが短すぎるとエラーになること' do
      fill_in 'user_name', with: 'サンプルユーザー'
      fill_in 'user_email', with: 'sample@email.com'
      fill_in 'user_password', with: 'p'
      fill_in 'user_password_confirmation', with: 'p'
      click_button '登録'
      expect(page).to have_content 'パスワードは8文字以上にしてください'
    end
  end
end

同じ事を何度も書いていてすごく…冗長です。でもまぁコピペでできるからよくない？と思うかもしれませんが、入力項目が後で追加されると全部修正していかなくてはなりません。それは面倒です。ですので、これもまとめておきましょう。ブロックを使います。FeatureHelpersに新しいメソッドを追加しましょう。

module FeatureHelpers
  # 略
  def input_and_submit_user_info
      fill_in 'user_name', with: 'サンプルユーザー'
      fill_in 'user_email', with: 'sample@email.com'
      fill_in 'user_password', with: 'password'
      fill_in 'user_password_confirmation', with: 'password'
      yield if block_given?
      click_button '登録'
  end
end

これを使って書き直してみます。

feature 'ユーザー管理' do
  background do
    create_user_and_login
    visit users_path
  end
  context 'ユーザー登録で' do
    background do
      click_link '新規作成'
    end
    scenario 'ユーザーを登録できること' do
      input_and_submit_user_info
      expect(page).to have_content '登録しました'
    end
    scenario '登録済みのメールアドレスはエラーになること' do
      input_and_submit_user_info do
        fill_in 'user_email', with: 'patorash@email.com' # 登録済みメールアドレス
      end
      expect(page).to have_content '既に登録済みです'
    end
    scenario 'パスワードが短すぎるとエラーになること' do
      input_and_submit_user_info do
        fill_in 'user_password', with: 'p'
        fill_in 'user_password_confirmation', with: 'p'
      end
      expect(page).to have_content 'パスワードは8文字以上にしてください'
    end
  end
end

登録ボタンを押す前に、入力項目を上書きするチャンスをブロックで与えています。こうすることで、フォーム入力を一部書き換えたい場合など、柔軟に対応できるようになりました。

テストもわかりやすさが重要！

とりあえず、以上が私がインテグレーションテストをする際に意識している点です。実践的な内容だと他にもあると思いますが、前回と今回で何が言いたかったかというと、『テストもわかりやすく、速く動くように書こう』ということです。何をテストしているのかわかりにくくなってしまうと、テスト自身が負債になってしまう可能性があります。まぁ、私の書き方がわかりにくいんじゃないか？という人もいるとは思います。これが正解でもありませんので、もっといい書き方などがあれば教えてください。

今日は木曜日だったので、ハンバーグの会（Okayama.rb）に参加してきました。

今日は@mako_wisにテストの書き方について相談を受けたので、粒度とかについて説明しましたが、私は説明し始めると早口になってしまうので詰め込みすぎたかもしれないと思ったのでちょっとまとめておこうと思いました。ちなみに、書き方といってもRSpecの始め方とかではないです。その点はあしからず。

Railsプロジェクトのいいところは、テストがとてもしやすいところだと思います。
私は今の会社に入るまで、テストは書きたいけれど、どう書けばいいのかわからなかったのと、頑張って書いてみたものの、成果が周りに評価されなかったのでこのままでいいのだろうか？と思い悩んでいました。しかし、既にテストがあるプロジェクトに入って書き方を学べた事と、同僚とThe RSpec Book読書会を社内で開いて勉強したおかげで、結構綺麗に書けるようになったんじゃないかな？と思ってます。持つべき物はいい仲間と向上心です(ｷﾘｯ

テスト戦略

まずテスト戦略についてです。
基本的にはテストは『開発者の不安を取り除くため』にあります。裏を返せば、不安でないところはテストを書く必要はありません。テストはやりすぎるとスピードが遅くなるし、ライブラリのテストをやっているようなことになってきます。ありそうなのは、Deviseを使ってユーザー認証作ってて、Deviseのテストになってしまっていたりとか。軽くならいいでしょうが、やりすぎはやめましょう。

どこまでテストするか？ですが、不安なところはテストしますが、重複しそうなところはやりません。以下のようなものをテストします。

• Model(ビジネスロジックが詰まってる)
• ActiveDecorator(Modelの延長なので)
• rake task(定期処理が多いから)
• インテグレーションテスト(Capybara + PhantomJS + poltergeist)

インテグレーションテストをするので、基本的にControllerとViewのテストはそちらで賄います。ただし、絶対にテストしないわけではありません。不安ならテストします。

どこからテストするのか？Modelでしょ！

Railsでテストが一番書きやすいのは、Modelです。どうしてテストしやすいかというと、

• テスト対象が明確である
• 依存関係が少ないので取りかかりやすい
• 高速である

という点です。まずはモデルのテストから書いて、慣れていく事をオススメします。

テストを定義してみる

では実際にRSpecでモデルのテストを書いてみるとしましょう。私はテストさえ書けば、テストを先に書こうが後に書こうがどっちでもいいと思います。どちらにしても最初に想定してないパターンとか思いつくので。でもモデルはテスト駆動しやすいと思うので、先に設計のつもりで書いたりすることが多いです。

たとえば、Userモデルがあって、名前、メールアドレス、パスワードを持っていて、登録するときには確認用パスワードが必須とします。
そうなると、こういう感じでテストが書けるかと思います。

require 'spec_helper'

describe User do
  context '正しいデータを入れた場合' do
    it "登録できること"
  end
  context '既にデータがある場合' do
    it '編集できること'
    it '削除できること'
  end
  describe 'エラーチェック' do
    context '何も入れない場合' do
      it 'エラーになること'
    end
    context 'メールアドレスでない場合' do
      it 'エラーになること'
    end
    context 'パスワードと確認用パスワードが一致しない場合' do
      it 'エラーになること'
    end
  end
end

とりあえず考えられるパターンを先に書き出しておきます。
it文だけ書いておくとpending状態になるので、思いつくがままに書いていると、仕様がテストに書き出されてきます。ちなみにdescribeとcontextはどちらでもいいのですが、contextを使う事で、テスト対象がどういう場合かを定義しておきます。describeはいくらでもネスト(入れ子)できますが、最後はcontextにするという感じです。よく使うパターンだと、

1. describe・・・〜で、〜であり
2. context・・・〜の場合
3. it・・・〜であること、〜でないこと

で終わります。

テストを実装してみる

では、次に、正しいデータを入れた場合、のテストを実装してみましょう。

context '正しいデータを入れた場合' do
  it "登録できること" do
    user = User.new(name: 'パトラッシュ',
                    email: 'patorash@email.com',
                    password: 'password',
                    password_confirmation: 'password')
    expect(user.save).to be_true
  end
end

普通に書くと、上のようになります。しかし、これから次は編集、削除のテストもあるのに、毎回User.newやUser.createを書くのは面倒です。そこで、テスト用データを作成しておきます。

FactoryGirlを使おう！

テスト用データの作成ですが、私はFactoryGirlを使って作っています。FactoryGirlは多機能なので色々できますが、まずはシンプルに使いましょう。

FactoryGirl.define do
  factory :user do |d|
    d.name 'パトラッシュ'
    d.email 'patorash@email.com'
    d.password 'password'
    d.password_confirmation 'password'
  end
  
  factory :user_invalid_password, parent: :user do |d|
    d.password 'invalid_password'
    d.password_confirmation 'wrong_password'
  end
end

親データを指定して、一部の値を書き換えたりすることができるので、想定できるパターンのユーザーを都度作成しておくと、どういう意図のテストデータかわかりやすくなります。例えばuser_invalid_passwordは、パスワードが違うテストデータという事になります。

FactoryGirlを使ってテストを直してみる

では、FactoryGirlを使って直してみます。FactoryGirl.buildを使うと、モデルにデータを入れて作成した状態(newした状態)になります（DBに保存はされていません）

context '正しいデータを入れた場合' do
  it "登録できること" do
    user = FactoryGirl.build(:user)
    expect(user.save).to be_true
  end
end

とてもシンプルになりました。

テスト対象を明確にしよう

さっきの修正でも十分機能はしていますが、さらに上を目指しましょう。何をテストしているのかを明確にするべきです。RSpecでは、テスト対象のオブジェクトを、subjectに設定することができます。こうすると、テスト内でsubjectと書くと、対象のオブジェクトにアクセスできます。

context '正しいデータを入れた場合' do
  subject { FactoryGirl.build(:user) }
  it "登録できること" do
    expect(subject.save).to be_true
  end
end

なんか、逆に長くない？と思われたかもしれません。そういうこともあります。ありますが、subjectがテスト対象であるというのが明確になりました。また、subjectに設定すると、英語圏の人はテストが書きやすくなります。日本語圏の我々は上の書き方でいいですが、一応紹介しておきます。

context '正しいデータを入れた場合' do
  subject { FactoryGirl.build(:user) }
  its(:save) { should be_true }
end

好きな方で書きましょう。私はどっちも使います。

次のテストをやってみよう！

次のテストは編集と削除です。事前にデータを登録することになりますが、これもFactoryGirlを使えば簡単です。FactoryGirl.createを使うと、対象のモデルをDBに保存までしてくれます。

context '既にデータがある場合' do
  before do
    @user = FactoryGirl.create(:user)
  end
  it '編集できること' do
    @user.name = "ネロ"
    expect(@user.save).to be_true
  end
  it '削除できること' do
    expect(@user.destroy).to be_true
  end
end

beforeを使えばテストの事前処理が、afterを使うとテストの後処理が定義できます。beforeは、:each, :allがあります(:aroundもあった気がする…)。省略すると、:eachになります。:eachは、テストのitが実行される毎に実行されます。:allは、そのフォーカスの中で1度だけ実行されます。基本的には、:eachを使います。:allはRSpecの事前定義とかで使います。

さて、勘のいい人は気付いたかもしれませんが、これ、subjectを使うともっと短くできます。

context '既にデータがある場合' do
  subject { FactoryGirl.create(:user) }
  it '編集できること' do
    subject.name = "ネロ"
    expect(subject.save).to be_true
  end
  it '削除できること' do
    expect(subject.destroy).to be_true
  end
end

テストシナリオを増やす

ここで、ふと気付きました。メールアドレスで認証しようと思っているのに、メールアドレスがユニークかどうかチェックしてないな、と。気付いた時点でとりあえずテストケースを書きましょう。

describe 'エラーチェック' do
  context '何も入れない場合' do
    it 'エラーになること'
  end
  context 'メールアドレスでない場合' do
    it 'エラーになること'
  end
  context 'パスワードと確認用パスワードが一致しない場合' do
    it 'エラーになること'
  end
  context 'メールアドレスが重複する場合' do
    it 'エラーになること'
  end
end

あとで追加しようと思うと、ど忘れしてしまうことが多いので、とりあえず書いて残しておきます。別にすぐテストの実装を書く必要はありません。

エラー系のテストを書く

では、エラー系を書いていきます。正常系が登録できなければならないのは当然ですが、イレギュラーなことをテストで書いておくと、すごく安心します。新しい機能を追加した結果、既存の機能に影響することはよくありますから、思いつくパターンはなるべく書きます。

Userモデルのバリデーションですが、

• 名前、メールアドレス、パスワードは必須
• メールアドレスは形式をチェック
• パスワードはパスワード確認と一致するかチェック

がされているものとします。

まずは、何も入れない場合のテスト。

describe 'エラーチェック' do
  context '何も入れない場合' do
    subject { User.new }
    it 'エラーになること' do
      expect(subject).not_to be_valid
      expect(subject).to have(1).errors_on(:name)
      expect(subject).to have(2).errors_on(:email)
      expect(subject).to have(2).errors_on(:password)
    end
  end
  context 'メールアドレスでない場合' do
    it 'エラーになること'
  end
  context 'パスワードと確認用パスワードが一致しない場合' do
    it 'エラーになること'
  end
  context 'メールアドレスが重複する場合' do
    it 'エラーになること'
  end
end

expect(subject).not_to が初めて出てきました。not_toは、〜でないことを確認します。ここでは、バリデーションの結果が正常でないことを確認しています。その後、各項目のエラー数をチェックしています。

次に、メールアドレスでない場合のテスト。

describe 'エラーチェック' do
  context '何も入れない場合' do
    subject { User.new }
    it 'エラーになること' do
      # 略
    end
  end
  context 'メールアドレスでない場合' do
    subject { FactoryGirl.build(:user, email: 'invalid_email') }
    it 'エラーになること' do
      expect(subject).not_to be_valid
      expect(subject).to have(1).errors_on(:email)
    end
  end
  context 'パスワードと確認用パスワードが一致しない場合' do
    it 'エラーになること'
  end
  context 'メールアドレスが重複する場合' do
    it 'エラーになること'
  end
end

FactoryGirl.buildで、2つめの引数にハッシュを渡しています。これは、FactoryGirlで作られるオブジェクトの項目を一部上書きすることができます。メールアドレスに適当な文字列を渡すようにしています。そして、正常でないことを確認して、emailがエラーを1つ持っていることを確認します。

次に、パスワードが一致しないとエラーになるテスト。

describe 'エラーチェック' do
  context '何も入れない場合' do
    subject { User.new }
    it 'エラーになること' do
      # 略
    end
  end
  context 'メールアドレスでない場合' do
    subject { FactoryGirl.build(:user, email: 'invalid_email') }
    it 'エラーになること' do
      # 略
    end
  end
  context 'パスワードと確認用パスワードが一致しない場合' do
    subject { FactoryGirl.build(:user,
                                password: 'hogehoge',
                                password_confirmation: 'piyopiyo') }
    it 'エラーになること' do
      expect(subject).not_to be_valid
      expect(subject).to have(1).errors_on(:password)
    end
  end
  context 'メールアドレスが重複する場合' do
    it 'エラーになること'
  end
end

ほぼ、メールアドレスの時と同じようなテストです。コピペして該当箇所を書き換えるだけですが、ずいぶん安心感があります。ここで、FactoryGirlのモデル変更項目が2つになりました。2つ程度なら、まぁそんなに苦ではないですが、これからカラム数が増えて複雑化してくると大変です。そこでFactoryGirlで前に作った、パスワードが違うモデルを使ってみましょう。

context 'パスワードと確認用パスワードが一致しない場合' do
  subject { FactoryGirl.build(:user_invalid_password) }
  it 'エラーになること' do
    expect(subject).not_to be_valid
    expect(subject).to have(1).errors_on(:password)
  end
end

いろんな状態のモデルを作るのは、FactoryGirlに任せると楽ですが、さっきのメールアドレスのテストのように、1項目だけの変更だったりすると、逆に面倒だったりするので、そこは使い分けましょう。

最後にメールアドレスの重複のテストです。
肝は、beforeブロックで事前にデータをDBに登録しておくところです。そして、全く同じモデルオブジェクトをFactoryGirl.buildで作ります。そうすると、必然的にメールアドレスが同じモデルができます。これを検証にかけて、エラーになるかどうかを試します。

describe 'エラーチェック' do
  context '何も入れない場合' do
    subject { User.new }
    it 'エラーになること' do
      # 略
    end
  end
  context 'メールアドレスでない場合' do
    subject { FactoryGirl.build(:user, email: 'invalid_email') }
    it 'エラーになること' do
      # 略
    end
  end
  context 'パスワードと確認用パスワードが一致しない場合' do
    subject { FactoryGirl.build(:user_invalid_password) }
    it 'エラーになること' do
      # 略
    end
  end
  context 'メールアドレスが重複する場合' do
    before do
      FactoryGirl.create(:user)
    end
    subject { FactoryGirl.build(:user) }
    it 'エラーになること' do
      expect(subject).not_to be_valid
      expect(subject).to have(1).errors_on(:email)
    end
  end
end

できました。シンプルなデータのマスターとかだと、これくらいのテストで済みます。

新しい制約ができたら？

たとえば、パスワードはこのままだと空文字じゃなければ1文字でもよくなる。せめて8文字以上にしたい。半角英数字と記号のみにしたい。という要望が出たとしたら、それもまたとりあえずテストに落とし込みます。

describe 'エラーチェック' do
  # 略
  context 'パスワードと確認用パスワードが一致しない場合' do
    subject { FactoryGirl.build(:user_invalid_password) }
    it 'エラーになること' do
      # 略
    end
  end
  context 'パスワードが短すぎる場合' do
    it 'エラーになること'
  end
  context 'パスワードに全角が含まれる場合' do
    it 'エラーになること'
  end
  # 略
end

これでもいいですが、パスワードが、パスワードがってうるさいですね。まとめましょう。

describe 'エラーチェック' do
  # 略
  describe 'パスワードが' do
    context '確認用パスワードと一致しない場合' do
      subject { FactoryGirl.build(:user_invalid_password) }
      it 'エラーになること' do
        # 略
      end
    end
    context '短すぎる場合' do
      it 'エラーになること'
    end
    context '全角が含まれる場合' do
      it 'エラーになること'
    end
  end
  # 略
end

こういうふうに、describeをネストすることで、テスト対象のスコープを狭くしていくことができます。テスト対象のスコープは常に意識しておきましょう。
他にも、似たような挙動を纏めるテストの書き方(shared_examples_for)や、遅延評価用変数の定義(let, let!)などありますが、それはおいおい覚えていってください。ググればでてくるでしょう。

正しいテストの書き方とは？

色々書いてきましたが、これが完全に正解かどうかは、わかりません。
私はテストしたいことがテストできていれば、書き方はどうでもいいと思います。上のような書き方は冗長じゃないか？と思う人もいるでしょう。自分で考えたり、チームで話し合って、わかりやすいものを採用すればそれでいいかなと思います。

長くなったので、インテグレーションテストなどについてはまた後で続きを書きます（違う記事にするかも）。