#TDDBC in Tokyo 1.5でのLT資料

1. TDDを実践してわかった
TDDつまづくあるあると
自分なりの乗り越え方まとめ
@remore

2. 今日、
僕たちが
経験すること

4. Kent Beck wrote:
TDDは分析技法および設
計技法であり、実際には
開発のすべてのアクティ
ビティを構造化するため
の技法である。
テスト駆動開発入門
p199

5. 「TDDは分析技法
および設計技法」

7. 「TDD＝テスト
ファースト？」
「テストコードを書く
だけでしょ？」

8. ＿＿＿_
／⌒ ⌒＼
／（ ●） （●）＼
／::::::⌒（__人__）⌒::::: ＼ 簡単だお！
| |r┬-| |
＼ `ー'´ ／
3か月前の@remore

9. ＿＿＿_
／⌒ ⌒＼
／（ ●） （●）＼
／::::::⌒（__人__）⌒::::: ＼ 簡単だお！
| |r┬-| |
＼ `ー'´ ／
後に現実を知ることになります

10. 今日はTDDをケントベッ
クのテスト駆動開発入門
で学んだ後、
僕の前に⽴ちはだかった
いくつかの現実と、
僕がそれをどう乗り越え
てきたかを紹介します

11. ※この物語は
割とノンフィ
クションです

12. @remoreについて
• ニジボックスでソーシャルアプリ開発
• アジャイルな開発手法の導入を進めてる
• 3か月前の自分：
– TDDは実践経験なし
• テスト駆動開発入門を読んだ知識だけ
– PHPUnitのインストール方法と簡単な使い方
はネットで調べて知った程度

13. TDD修行
TDD修行の旅
修行の
？？？？？？ |
■
■■
レガシーコード山脈
レガシーコード山脈 ■■■
▲▲▲▲▲
▲ ▲ ？？？？？
？？？？？？？
▲ ▲ ▲ ▲▲▲ ▲ ▲ ▲▲
▲ ▲ ▲▲ ▲ ▲
▲ ▲ ▲ ▲
▲ ▲ ▲ ▲ ▲
▲ ▲ ▲ ▲▲▲ ▲
▲ ▲
▲ ▲ ▲
▲ ▲ ▲
▲▲ ▲ ▲
▲ ▲
▲ ▲▲
▲ ▲▲
▲ ▲▲
▽スタート地点
スタート地点 ▲ ▲▲
▲

14. レガシーコード山脈
• テストコードのない実装が山のようにあ
る。
• 山の住⺠はソースコードの変更をした後、
周辺を含めて何も壊れていないことをき
ちんと確認する。そのあとは、結果がう
まくいくことを祈りながら暮らしている
と言われている

15. 僕が登った山
• 自社MVCフレームワークを使ったソー
シャルアプリのレガシーコード
• 言語はPHP
• ソースコードは10万⾏
– フレームワーク部分を除いて、Model,
Controller, Viewだけなら4000⾏くらい
※有効コード⾏数ベース
• テストコード⾏数は0

16. TDDつまづくあるある①
レガシーコード（テストコードのな
い実装）の山を目の当たりにして戦
意を喪失する。
（TDDをどのように現実の問題に適
用すればよいか、妙案が浮かばずに
途方に暮れている状態）

17. あると思います
（ありました）

18. 考え方：我流でGO
絶対的に正しいTDDの適用方法を知りたくなるのは人情だけど、多分状況は千
差万別なので、それを始めから⾒つけるのは困難。
失敗して傷つきながら自分なりのプラクティスを作っていく：
• MVCモデルでテストコードってどこから書けば良いのか
– Model → Controller → Viewの順番でテストコードを書いていく方針でやってます
• Controllerにかなりロジックがあって、テストできない部分が多い
– これ、地味にかなりヘコみます・・「面倒くさっ」ってなる
– まあ、Bad Designてことですよね。リファクタリングしないとね。Modelにテスト
コード書き終わったらやろう。
– テストコードを書きながら、Modelにコードを移していくイメージ
• Viewのテストコードはどうしようかな
– 仕組み上難しい場合も多そう（viewの中でechoしてたりだとか）
– @remoreの場合は、Viewにはテストコードを書いていない。（その代わりソース
コードレビュー他の設計技法は適用）

19. 時間がかかりやすいところ
• Modelのコードだけテストしようとしたけど、フレームワークの初期化処
理を経由しないとModelに配置されてるオブジェクトを使えなかった
– PHPUnitからModelを呼び出すために、テスティングフレームワーク内に、フレーム
ワークの初期化処理だけを抜き出したphpスクリプトを新たに用意した
• バッドノウハウでごめんなさい
• テストを実⾏する度に、テストコードから呼び出したModelのメソッドに
よってDBのレコードが変化していくので、何も考えないでテストを書いて
いくと、直前に成功していたテストコードが通らなったりする
– setUp()とtearDown()を活用して、どんな環境でも失敗しないフィクスチャを作る
– 例：
• setUp()で前回挿入したレコードを削除する
• テストコード内で使用するユーザ情報も設定しておく
– Datasetを比較するほど細かく内容をテストすることが現実的だと思えなかったので、
PHPUnitのデータベーステスト（PHPUnit/Extensions/Database/Testcase.php＝
DbUnitのポーティングを利用）はやらなかった
– StubやMockは使っていない
• 初めから使うことを想定して設計しておかないと使いづらい印象

20. 細かいけど書いておきたいこと
• PHPUnitだと、1テストファイルに1テストクラス
（PHPUnit_Framework_TestCaseの継承）しか書けない（っぽ
い）
– テストファイルを”*Test.php”っていうファイル名にしておけば、
phpunitコマンド実⾏時にフォルダ名を渡すことでフォルダ内全体（ネ
ストされているフォルダ含む）をテストしてくれる
• コードの可読性を重視して、テスト関数名に日本語でテストの目的
を書いておくのがオススメ（文字コードはUTF-8であればテスト実
⾏可能）

21. TDD修行
TDD修行の旅
修行の
生産性の
生産性の谷 |
■
■■
レガシーコード山脈
レガシーコード山脈 ■■■
▲▲▲▲▲
▲ ▲ ？？？？？
？？？？？？？
▲ ▲ ▲ ▲▲▲ ▲ ▲ ▲▲
▲ ▲ ▲▲ ▲ ▲
▲ ▲ ▲ ▲
▲ ▲ ▲ ▲ ▲
▲ ▲ ▲ ▲▲▲ ▲
▲ ▲
▲ ▲ ▲
▲ ▲ ▲
▲▲ ▲ ▲
▲ ▲
▲ ▲▲
▲ ▲▲
▲ ▲▲
▽スタート地点
スタート地点 ▲ ▲▲
▲

22. 生産性の谷
• レガシーコード山脈の難所の一つ
• 谷には開発者の不安を取り除くことができ
る財宝が眠っていると言われている
• 「テストコードは要らない。最速で実装を
終えよう。」という言い伝えを守り、山の
住人はこの谷には近づかずに生活している

23. 僕が落ちた谷
• 明らかに開発速度が落ちた
– この時期は「@remoreさん、今何してんすか？」と
いうリーダーからの問いに答えるのが怖かった
• 一時期、TDDから離れみたが、TDDをしないこと
によって、テストコードが取り除いてくれていた
不安が確かにあったことに気付かされた
• まあ、結局、開発速度が遅くなるのは自分が経験
不⾜なだけ

24. TDDつまづくあるある②
思ったよりもテストコードを書くと
開発が遅くなって（なったように感
じて）しまい、戦意を喪失する。
（TDDをやった方がいいと頭ではわ
かっていても、スキルが無いが為に
テストコードを書かない方がローリ
スクだと思い込んでしまう状態）

25. あると思います
（ありました）

26. とにかく経験値を積む[書き方編]
@remoreの場合、こんな経験を積んでいきました
• 例題演習
– ケントベックのテスト開発入門を写経したり
• 三角形を判定する関数をTDDで書いたり
• 演習問題と解答例をgithubに置いてます。
– https://github.com/remore/StudyTDD
– FizzBuzz()をTDDで書いたり
• 業務でレガシーコードにテストコードを追加した
り
• 新しく開発したツールやアプリにテストコードを
書いていったり

27. とにかく経験値を積む[運用編]
• 環境構築
– Jenkinsのインストールを繰り返し⾏った
– PhingやXdebugも使ってみた
– PHPUnit以外のテスティングフレームワーク
も試してみた
• PEAR非依存のlimeやSimpleTestならインストー
ルにつまづくこともなくてこちらもオススメ
• 必要だった覚悟とか
– 開発効率が下がったと思った分は残業してで
も同じパフォーマンスを出すつもりでやる

28. もがいているうちに
費用対効果について考え出した
• テストコードは1メソッドに対して1テストするだけで
も違う
– 「TDDは分析技法および設計技法」
– 1メソッドが無理なら、1つのクラスに対して1つテスト
コードを書くだけでも全然違う
• テストファーストをガリガリ回すのとは違っちゃうけど
– 何が違うかというと、こんなことを確認させてくれる（テ
スト駆動開発入門 p126より抜粋）
• 機能はどこに所属するのか。既存のメソッドの修正なのか、既
存クラスの新規メソッドなのか、新しい場所に実装される既存
のメソッドなのか、新規クラスなのか。
• どのような名前をつけるべきなのか
• 正しい答をどのようにチェックするのか
• 正しい答えは何か
• このテストから他のどのテストが提案されるのか

29. 費用対効果について
いま考えていること
• 作成するテストのパターンとボリュームは柔軟に考えればよい
– Kent Beckは「条件分岐、ループ、操作、多相性」の4つをテストする
ことを推奨しているけどね
– 無理にテストコードを追加しすぎると、テストコード地獄（書いても
書いても終わらない）にハマる
– でも自分の中の不安は無視しちゃダメ
• 例えば、デグレが頻出してる部分だけテストコードを書きながらリ
ファクタリングしてみるとか
– いきなり全部リファクタリングしようとしないこと。コードの量が⼤
きい場合は、十分に小さいサイズにリファクタすることで分割しなが
らテストコードを追加していく。
• それとか、他の設計手法を交えることで割り切ることも時に有効
– 例：Viewのコードは不安が少ないからテストコードは書かずにソース
コードレビューだけしておこう

30. TDD修行
TDD修行の旅
修行の
生産性の
生産性の谷 |
■
■■
レガシーコード山脈
レガシーコード山脈 ■■■
▲▲▲▲▲
▲ ▲ 自己満足の
自己満足の砦
▲ ▲ ▲ ▲▲▲ ▲ ▲ ▲▲
▲ ▲ ▲▲ ▲ ▲
▲ ▲ ▲ ▲
▲ ▲ ▲ ▲ ▲
▲ ▲ ▲ ▲▲▲ ▲
▲ ▲
▲ ▲ ▲
▲ ▲ ▲
▲▲ ▲ ▲
▲ ▲
▲ ▲▲
▲ ▲▲
▲ ▲▲
▽スタート地点
スタート地点 ▲ ▲▲
▲

31. 自己満足の砦
• 無関心と自信喪失に満ちた砦
• レガシーコード山脈を越えると⾒えてくる
• どんなに速くテストコードを書いても、テスト
コードのおかげで潜在的なバグを修正できても、
複雑に作られた自己満足の砦を抜け出すことは困
難と言われている
• テストコードが通らなくて時間をとられてしまい、
自信を失い、心が折れる旅人も多い

32. 意外に多くの勇者が一人で燃え尽
きてるんじゃないか説
• 自己満足という側面
– どんなに速くテストコードを書いても、
– テストコードのおかげで潜在的なバグを修正できても
– 誰にも褒められない
• 自信を失いやすいという側面
– テストコードが通らない時間は単純に苦痛
– テストが通らない（＝レッド）まま数時間使ってしまった
時の無⼒感は異常
• 理想に燃えて始めたはずのTDD。その理想が仇になっ
て、理想と現実のギャップがここでボディーブローの
ようにきいてくる

33. TDDつまづくあるある③
かけた努⼒の割に報われ難いように
思い込んでしまい、次第に戦意を喪
失していく。
（上手に説明しないと他人からは理
解されにくいことがままあって、や
さぐれてるうちに次第に熱が冷めて
元のレガシーな頭に戻っていく）

34. あると思います
（ありました）

35. アウトプットを心がける
• 誰かに話す（共感してもらう）
– 会社でTDDしててつまづいたら同僚に
• そしてテストコードを追加したいと思ってくれるチームのリー
ダーやメンバー、同僚、勉強会の皆さんに感謝を
– プライベートの開発でつまづいたら勉強会で
• というわけで、僕のここ数か月のつまづきをお話しさせても
らって英気を養ってます。TDDBC in Tokyoの皆さんありがと
うございます。
– 勉強会を主催しちゃうのも一つの手
• 成果を上手にアピールする
– Assertを追加したテストコードをリポジトリにcommitす
る時、堂々と”25Assert追加”のようにコメントに書く事
を習慣化する
– 勉強会でLTさせてもらったりブログを書いて反響を頂いた
り

36. アウトプットする前に燃え尽きて
しまいそうな時に読む精神論
• TDDはレッド、グリーン、リファクタリング
のリズムが⼤事。だけど、リズムが壊れたか
らといって自分の能⼒が低いわけじゃないと
開き直れるかどうか。
• レッドの場合、自分が書いたコードに問題が
ある場合が実際に多い。つまり、現実と向き
合えるかどうかが問われる。
• 問題を先延ばしにしない強い心を。
• 焦らないでOK。初めは時間がかかるものと
心得て、みんなで強い意志で取り組む。

37. 最近の僕のTDD使い方まとめ
• レガシーコードと泥臭く戦う。
– MVCならModelから少しずつ
– Contorllerに残ってるコードはテストコードを書きながらリファクタリ
ングしていく（＝仕様化テストの導入）
• 自分の経験不足を言い訳にしない
– テストコードを書くと生産性が落ちるのは自分のせい
– 書くテストコードの量は、1パターンでも書くと全然違う
– TDDで戦うところとそうでないところ、割り切りも⼤事
• 一人で戦わない。仲間と戦う。
– 孤独との戦いもある
– レッド、グリーン、リファクタリングのリズムが崩れてもファイティ
ングポーズをとれるか。
– つらかったら話を聞いてもらうだけでも違う

38. [付録] 読んでおくべきTDD関連の
ソース
• 三周遅れのXP
– http://www.slideshare.net/yoshiori/xp-
3242327
• 読んでおくべきテスト関係のTL
– http://togetter.com/li/5878
– http://togetter.com/li/6759
– http://togetter.com/li/6923