Refactoring And Test

Slide 1: リファクタリングとテストの関係 twada http://d.hatena.ne.jp/twada/ @J2EE勉強会 2005年8月20日

Slide 2: 前回のおさらい

Slide 3: 前回の結論(1) ● TDDはテスト技術ではない ● "Test"が指し示しているものは複数ある – 開発促進と品質保証 – 2つの"Test"に優劣はない。「違う」だけ。 – どちらも非常に重要 ● テストをロールから分類する – 開発者 / 顧客 / 品質保証担当者

Slide 4: 前回の結論(2) ● TDDの"Test"は開発(者)のためのもの – つまり、開発促進のテスト ● TDDの良さは設計技術でありながら品質保証技術に「かなり近い」こと

Slide 5: 難しくなったソフトウェア開発 ● ソフトウェアの複雑化 ● ソフトウェアの大規模化 ● プロジェクトの短納期化 ● オブジェクト指向も(それなりに)使われだした →ソフトウェアの品質が問題に(日経ビジネス) →「テスト」が注目されてきた

Slide 6: テスト分類の混乱 ● 単体、ユニット、結合、機能、システム… ● 単体テストとユニットテストは同じもの? – 単体って? – ユニットって? ● 結合テストは何を結合する? ● 品質保証? 動作確認? ● だれが? いつ?

Slide 7: テストの目的に戻ろう ● 何のためにテストするのか ● 誰のためにテストをするのか ● テストで何を知りたいのか「結局、何のためにテストを行うのか」

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

Slide 9: 「テスト」 Developer Customer QA Test Test Test

Slide 10: それぞれのテストの目的 ● Developer Test – 開発促進 – フィードバックを伴う設計行為 ● Customer Test – 進捗管理 – 機能要件の検証 ● QA Test – 品質保証 – 非機能要件の検証

Slide 11: 「テスト」 Developer Customer QA Test Test Test 開発促進進捗管理品質保証設計行為機能要件非機能要件

Slide 12: TDD != 品質保証技術 ● TDDは「こうしてみようか」をテストする ● QAテストは「こうあってはならない」をテストする TDDは品質向上技術だが、品質保証技術ではない。そもそも「品質」の話が必要あなたにとっての「品質」とは何ですか?

Slide 13: TDDは設計技法です ● 文脈 – プログラミングは設計行為である(J.Reeves) – REDは仕様の設計 – GREENは仕様の実装 – Refactoringは内部設計の改善参考：「ソフトウェア設計とは何か？」 http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

Slide 14: TDDと品質保証の関係 ● 目的は違えど、手段が品質保証技術に近い ● 品質保証との親和性 ● 帽子を変えることで品質保証モードに入れる

Slide 15: 前回の発表のねらい ● 議論の土台を作ること ● 目的の視点からみたテストの整理 – Developer Testの概念の紹介 ● TDDのTはDeveloper Testであることを理解してもらう – 品質保証のための技術ではなく、開発促進のための技術

Slide 16: 今回のお題

Slide 17: 今日伝えたいこと(1) ● リファクタリングの目的はコードの理解や修正が簡単になるようにすること ● リファクタリングは設計意志決定のバランスをとる

Slide 18: 今日伝えたいこと(2) ● テストがリファクタリングを妨げるのは何かがおかしい ● リファクタリングを後押しするテストと、リファクタリングの役に立たないテストがある ● 目的に沿ってDeveloper Testを使いこなそう

Slide 19: 第一部

Slide 20: リファクタリングについての整理

Slide 21: リファクタリングをめぐる混乱 ● 三週間ほど前、リファクタリングをめぐって議論が繰り広げられました ● ひとりひとりが結ぶ「リファクタリング」の像が異なるという印象「テスト」と同じ混乱の構図か

Slide 22: リファクタリングの定義(1) リファクタリング（名詞）外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変更させること。

Slide 23: リファクタリングの定義(2) リファクタリング（動詞）一連のリファクタリングを行って、外部から見た振る舞いの変更なしに、ソフトウェアを再構築すること。

Slide 24: リファクタリングの解釈のブレ ● 外部から見た振る舞い – 外部? – 振る舞い? – public? publish? ● テストで担保する? ● パフォーマンス?

Slide 25: 「テスト」と同じ混乱の構図 ● 違う内容のものを同じ名前で呼んでいる – 「テスト」の意味合いの違い – 「外部から」の意味合いの違い誰が、何のために、で再整理しましょう

Slide 26: リファクタリングの「誰が」 ● これは、私たちプログラマーです ● 自分達で、自分達のコードをわかりやすく、シンプルにするのがリファクタリング – 他の人が書いたコードを理解のためにリファクタすることはあるが、特殊例

Slide 27: リファクタリングの「何のために」 ● シンプル設計 ● コードを理解しやすく ● コードを修正しやすく ● コードをシンプルにすること ≒ 設計をシンプルにすること大目的「理解や修正が簡単になるように」

Slide 28: 何がリファクタリングへと駆り立てるのか(RtPより) ● 新しいコードを追加しやすくしたいため ● 既存のコードの設計を改善したいため ● コードをより良く理解したいため ● コーディングの不快感を減らしたいため

Slide 29: リファクタリングの「いつ」 ● 教条的なことを言うなら、「常に」です ● 気づいたときに ● サイクルに織り込んでいるのがTDD ● 「大きいリファクタリング」は、話が別 ● 小規模なリファクタリングは機械でも出来るし、いつもやっていることです – rename系、extract系、inline系

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

Slide 31: パフォーマンスチューニング? ● パフォーマンスのためにリファクタすることはほとんどない ● まず計ってからものを言うべし ● 普通はデータベースがボトルネック、コードを見るよりExplain Planするべし!

Slide 32: 「シンプル」とは何か ● コンテクストに依存する – チームで決めること – チームによってなにがシンプルかが変わる ● パターンはシンプルさのために使う – Compositeの方が単純なとき – Strategyの方が単純なとき ● 分岐から構造へ

Slide 33: まとめると

Slide 34: リファクタリング、私の理解 ● 目的は、理解や修正が簡単になるように ● 設計行為としてのリファクタリング ● 外部からみた振る舞い – publishedメソッドの事前条件と事後条件のこと – publishedメソッドの変更もときどきリファクタリングと呼んでいます ● 「テスト」 – 大きい粒度のテスト、Mockベースのテストではなくて実オブジェクトベースのテスト

Slide 35: テストがあるリファクタリングテストがない private public published protected

Slide 36: リファクタリング前提の設計? ● 逆を考えるとわかりやすい – 「一発で正しい設計を行え、修正や改善は許可しない」と言われたら? ● 「修正が効かない」というプレッシャーをあたえると人間は脆い ● テストとバージョン管理で安全に後戻りができるようになる – 安心して前に進むことができるようになる

Slide 37: 技術的負債 ● スケジュールの無い開発は存在しない ● 負債を追ってでもリリースを優先することも ● リファクタリングで負債を減らしていく ● 「ええい、やめだやめだ、スクラッチから書き直そう!」とならないために ● リファクタリングは「捨てない技術」

Slide 38: 道はひとつではない ● 「動作する、きれいなコード」 ● きれいな、から攻めるか ● 動作する、から攻めるか

Slide 39: きれい汚い (すぐには)動かない動作する

Slide 43: TDDのテンポ ● Red, Green, Refactor ● Red, Green, Commit, Refactor, Green, Commit 「動作する」を満たしてから「きれいな」にとりかかる

Slide 45: きれい d Re 汚い (すぐには)動かない動作する

Slide 46: きれい d Re 汚い Green (すぐには)動かない動作する

Slide 47: きれい Refactor 汚い Green (すぐには)動かない動作する

Slide 48: きれい Refactor d Re 汚い (すぐには)動かない動作する

Slide 49: きれい d Re 汚い Green (すぐには)動かない動作する

Slide 50: きれい Refactor 汚い Green (すぐには)動かない動作する

Slide 51: きれい Refactor d Re 汚い Green (すぐには)動かない動作する

Slide 52: リターンマッチは可能だ ● 設計の善し悪しは、最初に設計したときには決まらない ● だんだんと「より良い」設計に変えていくことが出来る – ただし、非常に大規模なアーキテクチャ変更は別 ● メジャーバージョンアップ ● システムのリプレース

Slide 53: 進化的設計(Evolutionary Design) ● フレームワークは最後に出来る ● ボトムアップ ● フィードバックここで提示しているのは極論かもしれませんが、こんな考え方もあることを紹介したいのです。

Slide 54: 第二部

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

Slide 56: テストの資産価値 ● リファクタリングの邪魔になるようなテストは価値が低い ● テストはリファクタリングの支えになるものであって、妨げになるものではない ● どのテストもメンテナンスコストはかかる ● 半年後であっても読みやすく、リファクタリングの支えになるテストは資産価値が高い

Slide 57: 再度Developer Testを分類する必要が出てきました

Slide 58: Developer Testの分類のキーポイント ● 目的 ● 粒度 ● 何を担保するのか ● フィードバックまでの時間 ● 資産価値 ● メンテナンスコスト ● 設計改善効果

Slide 59: Developer Testを目的と粒度で分類する ● Unit Test – テスト対象以外は全てMock ● Assembly Test – テスト対象のコラボレータは本物を使う ● Functional Test – コンポーネントをブラックボックスとして扱う – 永続化層も本物

Slide 60: Developer Customer QA Test Test Test

Slide 61: Developer Test Functional Test Customer QA Assembly Test Test Test Unit Test

Slide 62: Developer Testの分類、もうひとつの視点

Slide 63: インタラクションベーステスト ● テスト対象のオブジェクトがコラボレータときちんと相互作用するかどうかを検証する ● Mockを多用する – テストの初めでコラボレータのMockを作成 – Mockにexpectationをセット – テストの最後でMockをverify

Slide 64: ステートベーステスト ● テスト対象のオブジェクトの振る舞いの事前条件、事後条件を検証する ● setUpでデータを準備 ● assertEquals等で事後条件のチェック

Slide 65: Functional Test Assembly Test Unit Test ステートベースインタラクションベース

Slide 66: リファクタリングを担保するテストとは ● ある程度大きい粒度のテストでないと、リファクタリングの前後を担保できない ● インタラクションベースのテストはリファクタリングの役にたたないことが多い

Slide 67: リファクタリングの誤解 ● 「リファクタリング前後でテストが失敗してはならない」? 担保するテストはGreen to Greenであるべししかし、全てのテストがGreen to Greenとは限らない

Slide 68: リファクタリングの最中には ● ステートベースのテストは失敗しない ● インタラクションベースのテストは失敗してもいい ● あくまで「想定の範囲内」であれば、ですが

Slide 69: なぜインタラクションベースのテストは失敗してもいいのか ● 内部設計を改善するということは、オブジェクトたちの相互作用(インタラクション)も変わる可能性が高い – 責務の再配置には、インタラクションの変更がつき従う – インタラクションが変わるのは悪いことではなく、良いこと

Slide 70: リファクタリングの支えになりにくい領域 Functional Test Assembly Test Unit Test ステートベースインタラクションベース

Slide 71: リファクタリングの支えになりにくい領域 Developer Test Functional Test Customer QA Assembly Test Test Test Unit Test

Slide 72: 私のチームがテストの粒度に使っているメタファ ● はしご ● 踏台 ● 階段 ● 調子のいいときには三段飛ばし ● 心配なときには一段ずつ

Slide 73: トップダウンとボトムアップ ● インタラクションベースのテストだけを積み上げて正解に辿り着くのは難しい ● 受け入れテストだけを拠り所に開発を行うのは足場が少なすぎる

Slide 74: 足りないピースは?

Slide 75: 低コストな機能(Functional)テスト ● 大きいリファクタリングのキーポイント ● 機能のブラックボックステストをいかに低コストで行うかがカギ ● 例えばJ2EEであれば – Selenium – HttpUnit – Cactus

Slide 76: Mockでテストできないもの ● オブジェクトたちが実際に協調して動くこと ● Mockは妄想。妄想でもインタラクションの設計はできる ● 詳細なシーケンス図と役割が似ている? – 違いはコードで書かれること – 図とコードの距離

Slide 77: インタラクションベーステスト (Mock)のデメリット ● 価値が前方(気づき)に集中する ● メンテナンスコストが結構高い ● テストがなかなか資産化しない => 資産価値が低い

Slide 78: 最後にちょっと Mockテストの弁護をします

Slide 79: Mockのメリット(1) ● フィードバックの早さ – MockのテストはGreenにするまでの時間が短い ● 例外系のテストが行いやすい – ネットワークエラー – データベースエラー

Slide 80: Mockのメリット(2) ● 悪い設計に気づくまでの時間が短い – Mockのセットアップがめんどくさい => インタラクションが複雑 – Mockを沢山作らなければならない => デメテルの法則に反している ● 責任の配置を考える機会が増える – Tell, don't Ask – QueryからCommandへ

Slide 81: テスト設計の勘どころは、次回以降をご期待ください

Slide 82: 今日伝えたかったこと(1) ● リファクタリングの目的はコードの理解や修正が簡単になるようにすること ● リファクタリングは設計意志決定のバランスをとる

Slide 83: 今日伝えたかったこと(2) ● テストがリファクタリングを妨げるのは何かがおかしい ● リファクタリングを後押しするテストと、リファクタリングの役に立たないテストがある ● 目的に沿ってDeveloper Testを使いこなそう

Slide 84: Enjoy Testing!

Slide 85: Special Thanks ● J2EE勉強会に参加されているみなさま ● 角田さん ● ひがさん ● 中村さん ● 稚内北星学園大学様(会場提供ありがとうございます) ● かくたにさん ● kdmsnrさん (今回はblikiに本当に御世話になりました) ● TDD,Refactoringを編みだしたKent Beck氏 ● そして、それを私に教えてくれた、masarlさん

Slide 86: ご静聴ありがとうございました

Slideshare.net (beta)