リファクタリングとテストの関係

test agile

t-wadaさんのリファクタリングとテストの関係では、テストとリファクタリング、TDDの考え方が分かりやすく説明されている。

「動作する」を満たしてから、「きれいな」にとりかかる

  • Red, Green, Refactor
  • Red, Green, Commit, Refactor, Green, Commit

Refactor

そのほか印象に残ったスライドを引用：

テストの目的に戻ろう

  • 何のためにテストするのか
  • 誰のためにテストをするのか
  • テストで何を知りたいのか

テストをロールによって分類する

  • Developer(Programmer) Test
    • 開発者が行う、開発促進のためのテスト
    • 単体、ユニット、結合 …などなど
  • Customer Test
    • 顧客(のロールを担うひと)が行うテスト
    • 従来の「受け入れテスト」が多くを占める
  • QA Test
    • 品質保証のためのテスト
    • 行う人は開発者かもしれないし、テスト担当者

かもしれない

それぞれのテストの目的

  • Developer Test
    • 開発促進
    • フィードバックを伴う設計行為
  • Customer Test
  • QA Test
    • 品質保証
    • 非機能要件の検証

リファクタリングの目的はコードの理解や修
正が簡単になるようにすること

リファクタリングの「何のために」

  • シンプル設計
  • コードを理解しやすく
  • コードを修正しやすく
  • コードをシンプルにすること ≒ 設計をシンプルにすること

大目的「理解や修正が簡単になるように」

リファクタリングは何ではないのか

  • 非公開メソッドの中だけではない
  • パフォーマンスチューニングではない
  • バグフィクスではない
  • 他人のひどいコードの手直しではない
  • 手戻りではない (Refactoring is not rework)

道はひとつではない

  • 「動作する、きれいなコード」
  • きれいな、から攻めるか
  • 動作する、から攻めるか

リターンマッチは可能だ

  • 設計の善し悪しは、最初に設計したときには決まらない
  • だんだんと「より良い」設計に変えていくことが出来る

リファクタリングをサポートするテストとは何か

Developer Testを目的と粒度で分類する

インタラクションベーステスト

  • テスト対象のオブジェクトがコラボレータと

きちんと相互作用するかどうかを検証する

  • Mockを多用する
    • テストの初めでコラボレータのMockを作成
    • Mockにexpectationをセット
    • テストの最後でMockをverify

ステートベーステスト

  • テスト対象のオブジェクトの振る舞いの事前

条件、事後条件を検証する

  • setUpでデータを準備
  • assertEquals等で事後条件のチェック

リファクタリングの最中には

  • ステートベースのテストは失敗しない
  • インタラクションベースのテストは失敗して

もいい

    • 内部設計を改善するということは、オブジェクトたちの相互作用(インタラクション)も変わる可能性が高いため