Skip to content

Instantly share code, notes, and snippets.

@yasuoza
Created December 22, 2012 09:11
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save yasuoza/4358171 to your computer and use it in GitHub Desktop.
Save yasuoza/4358171 to your computer and use it in GitHub Desktop.
TDDを取り入れたい誰かのために

このエントリはTDD Advent Calendar jp: 2012の22日目のエントリです。 昨日は@fukayatsuさんのTDDを続けるためにでした。

世界終わらなくてよかったですね!Hello world!

というわけで今日はTDDをチームや社内で導入するために僕がやったことや、失敗したことなどを共有できたらいいなと思い、エントリを書きます。

まず、すでに社内全体でTDDを導入できている人はこのエントリを読む必要はありません。僕に伝えられることは何もありません。ここで読み終わってOKです。

つぎに、社内やチーム内の重要ポストの人がTDDやテスト自動化なんて意味なし、無駄なことだと思っている場合は、TDDがすでに定着している会社に転職をするといいと思います。僕に伝えられることは何もありません。ここで読み終わってOKです。

さて、ここからは今の組織がまぁまぁ好きで、そんな好きな組織にTDDを普及させたいと思っている人だけが読んでいることになります。 そして、このエントリ内でのTDDの定義をきちんとしたいと思います。このエントリではTDDを「テストを書いて自動化する行為」と定義します。なので、いわゆるテストファーストこそがTDD、それ以外は認められない!みたいなスタンスではありません。ここ、非常に重要です。

それでは実際にテストを普及させるために大事だと僕が思っていることを書いていきます。

余談ですが僕はreturn firstが好きです。ロジックの見通しが良くなるからです。

なぜテストを書くことが必要かを考える

そもそも論が必要です。逆説的ですが、僕はプログラマの仕事はコードを書かないで良くすることだと思っています。それなのになぜプロダクトコードだけじゃなくテストコードも書かないといけないのか、それを自分のチーム・社内に沿って考えるといいのではないかと思います。

image

自分がテストを書けるようになる

テスト大事!となったらいざテストを書いていくわけですが、全くテストの技法を知らないと、いわゆる「テストが大事なのは知っているけど、書けてない」という状態に陥ります。僕が在籍していた会社もそうでした。「テスト書きたいけど、どうやって書いたらいいかわからない」というありがちな空気が漂ってました。
最初は旗をかざして先導する人が必要です。誰かを待っている場合ではありません。githubに上がっているそこそこ有名なプロジェクトのテストコードを読むのでもいいしTDDBCに参加することでも確実に勉強できます。
また、始めっから完璧でカバレッジも80%以上のテストを書く必要はありません。書きやすいメソッドからテストを書いたり、次から書くコードに対してのテストを書くと敷居が低くてオススメです。とにかく少しずつテストを書いていきましょう。

image

テストを書いてみせる

実際にテストを書いてみせることが重要です。テストを書きたいけど、書けない人の参考になります。誰もがはじめはコピペプログラマだと思います。コピペ元になるコードを書きましょう。

image

楽しい雰囲気を醸し出す

テストコードが書いてあるリファクタリングたのしー!など連呼しましょう。すぐにTDDが普及することはありません。あきらめず、少しずつ仲間を増やしましょう。

image

テストの押し売りをしない

世の中にはTDDゴリ押しの人も少なからずいます。「テスト書かないの?死にたいの?」のように言ってくる人もいるでしょう。

僕がそうでした。テストいい、すごくいいとただ騒いでいる人になっていました。

そうなるとテストを書けていない人やテストを書く意味がないと思っている人との距離はどんどん広がるばかりです。テストを書く意味についてその必要性からもう一度ざっくばらんに議論するといいと思います。

image

テストファーストにこだわり過ぎない

ELOQUENT RUBYで言及されてましたが、ビジネスは時間との戦いです。テストファーストが常に正しい訳ではありません。テストを書くのがプロダクトコードの後になってしまうこともあるとおもいます。テストファーストはテストを書くことに慣れてきてから取り入れるようにすればいいと思います。

image

まとめ

TDDを普及させるためには、諦めない気持ちが必要です。まぁまぁ好きな組織なのですから、そこは諦めてはいけません。「愛せよさもなくば捨てよ」(情熱プログラマー ソフトウェア開発者の幸せな生き方)の精神です。
僕は幸いにも社内の雰囲気が「テスト書けるといいよね」という感じだったので、僕がテストの書き方を勉強して、社内勉強会でその方法を共有したり、実際にテストを書いて、こんなテストを書きましたーみたいに発信することで、急激にTDDが普及していったと感じています。 その後、別の会社に転職しましたが、前職の人の個人githubにきちんとテストがついたリポジトリが上がったりして、テストは大事だと思っている僕にとっては嬉しい限りでした。
このエントリがTDDを取り入れたい誰かのお役に立てば幸いです。

明日は@k_0kamotoさんです!1000行を越えるメソッドのテストなんて僕は経験したことがないので、非常に楽しみです!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment