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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[付録] 読んでおくべき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

http://www.infiniteloop.co.jp	4276
http://d.hatena.ne.jp	1407
http://rimuru.lunanet.gr.jp	1268
http://hiroki.jp	480
http://paper.li	75
url_unknown	44
http://twitter.com	28
http://webcache.googleusercontent.com	12
http://techtalk.nekoget.com	11
https://twitter.com	10
http://192.168.3.100	6
http://www.slideshare.net	6
http://tweetedtimes.com	4
http://us-w1.rockmelt.com	2
http://s.deeeki.com	1
http://remore.lunanet.gr.jp	1
http://tweetlog.jp	1
http://jp.hanrss.com	1
http://twicli.neocat.jp	1
http://shutto.com	1
http://a0.twimg.com	1
http://b.hatena.ne.jp	1
http://www.iflp.jp	1

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

by Kei Sawada on Jul 08, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

23 Embeds 7,638

Statistics

TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ — Presentation Transcript