「EFFECTIVE TESTING WITH RSPEC 3: BUILD RUBY APPS WITH CONFIDENCE」の3章を読んだ

あとから自分で読み直せるように、ブログにまとめつつ読んでいます。

RSpecの流儀(The RSpec Way)

Specがあなたにもたらすもの(What Your Specs Are Doing For You)

  • クリエイティングへの自信
  • 恐れの除去
  • リファクタリングの行いやすさ
  • 設計デザイン
  • 持続性
  • ドキュメント化された挙動
  • ワークフロー(働き方)の変化
  • It's Fun!(自分で設定を決めて、それをクリアするのはまるでゲームみたいで面白い)

やりすぎるな!(Don't Overdo it!)

歴史的に、開発者はアプリケーションに十分なテストコードがないことに不満を言ってきた。だからこそ、今はTDD(テスト駆動開発)が主流になっている。しかし、ぼくらは逆の問題も見るようになっている。オーバーテスティングに苦しむプロジェクトだ。

Specsの異なる型(Different Types of Specs)

Specsの型は、大別すると3つに分けることが出来る。

  • Acceptance: システム全体が機能するか?
  • Unit: オブジェクトが正しく働き、機能し合えるほど便利であるか?
  • Integration: 変更することができなかったコードについて、自分たちのコードが正しく機能するか?

一つずつ見ていこう。

受け入れテスト(Acceptance Spec)

受け入れテストは、end-to-endにおけるある機能について説明し、ブラックボックススタイルがシステム全体で働いている。

こういったテストは記述が困難で、比較的壊れやすく、そして遅い。しかし、大規模なリファクタリングを行うさいは、極めて重要だ。

単体テスト (Unit Specs)

ある一つのメソッドやオブジェクトについて、そのために構成した環境と関連し合いながら、正しく振る舞うかどうかをテストする。

正しく書かれた単体テストはとても早く走るし、それらの独立性は有用性の高い設計フィードバックを与えてくれる。

しかし一方で、それらの単体テストは大規模なリファクタリングの際は効果を発揮しきれない傾向にある。だから、リファクタリングの際は、ときどきそれらの単体テストを破棄する必要がある。単体テストのために大きな犠牲を払うべきではない。

統合テスト(Integration Specs)

統合テストは上に挙げた2つのテストの間に位置する。コードはDBや外部ライブラリといった外側のサービスと関連する。

  • 単体テストは外部ライブラリから孤立させる
  • 統合テストは外部ライブラリに直接関連させる。(比較的遅くなりやすい)

統合テストはときどき嫌になるぐらい遅いが、コミット前には実行することをおすすめしている。