Sue445 Style TDD

@sue445

2012/09/08 Androidテスト勉強会

Agenda

• 宣伝とか• 「テスト」について• TDDについて

• おまけ

お前誰よ？

末吉剛 (@sue445)

元 SI(Java), 今ドリコム (Rails)

クラスタ

• Google App Engine

• TDD

• Agile渋谷

• 渋谷 .rb

• ニチアサ・ニチヨル・オリーブ実況

あずにゃんペロペロ〜

http://azusaar.appspot.com/

第 2期開始！

http://azusaar.appspot.com/

黄色あざとい

あざといは正義

宣伝

TDD Advent Calendar jp: 2011

https://gihyo.jp/dp/sp/advent2011/G11C28

で epubが無料配信中！

TDD Advent Calendar jp: 2011

僕の TDD動画が収録されているため 145MBwww

Androidでのテストについて

Androidでのテストについて

@shuji_w6eさんが執筆中の「 JUnit実践入門（仮）」に全部書いてあるので割愛（今秋発売予定）

ここから本編

「テスト」について

「テスト」と一言で言っても意味が広いので整理してみる

「テスト」について

開発促進 (TDD)

開発者

Developer Tesing

品質

QA Tesingセキュリティ、バグとか

顧客

Customer Tesing

機能、進捗管理

「テスト」について

開発者

Developer Tesing

品質

QA Tesing

顧客

Customer Tesing全部大事！

TDDについて

TDDについて

Fateは文学CLANNADは人生Railsは哲学

TDDは設計

TDDは設計

TDDって何？

TDD = Test Driven Development

一言で言えば、テストコードとプロダクトコードをほぼ同時進行で書くこと

とある TDDプログラマの日常

1. これから実装しようとする機能のテストを書く

2. テストを動かして Redになるのを確認す3. プロダクトコードを書く4. テストを動かして Greenになるのを確認する

5. テストが動くままでコードをきれいにする(Refactoring)

6. 1に戻る

TDDと黄金の回転

Red Green

Reafactring

落ちているテストを通す

テストが通るままでコードをキレイにす

る

新しいテストを書く

Robert C. Martin 曰く (TDD三原則 )

• 失敗する単体テストのコードを書く前に、製品のコードを書いてはならない

• コンパイルが通り、適切に失敗する単体テストができるまでは、次の単体テストを書いてはならない

• 現在失敗している単体テストが通るまで、次の製品コードを書いてはならない

テストファーストの重要性

• テストを書くには何が必要？o 入力（引数）o 出力（戻り値、画面出力）o クラスやメソッドの役割、パターン分け

• これって設計じゃね？o 作りたいものが明確になっていないと何も作れないo 先にテストを書くことであやふやな仕様が浮き彫りになる

• Redになるテストが先にあることで、 Greenになった時に自分が考えた通り実装できたことが実感できる

TDDをする一般的な理由

• 健康のためo 変化に対応できるのは健康体のコードo 変化に対応できるのは健康体のチーム

• 素早くフィードバックを得るためo 自分が書いたコードが動くかどうかをすぐに確認できる

• 不安をテストにすることで精神的な安定を得る

• 工数は 2割増しの代わりにバグが半分になるというデータも出ているo t_wadaさんのスライド参照 http://www.slideshare.net/t_wada/t

ddbc-fukuoka-day1/64

僕が TDDをする理由

自分が楽をするため

働きたくないでござる

僕が TDDをする理由

• 自分が楽をするためo ブラウザリロードするよりコマンド叩く方が楽o テストしやすいコードは自然に DRYとか SRPもできてくるo テストがあると恐れずにリファクタリングができる

• とりあえず動かせるo コードは動かしてなんぼ

• 結局のところ先に苦労するか後に苦労するかの違いo ただ、バグは早い段階で見つけて修正した方が楽o 開発中＜結合テスト中＜ QA＜リリース後

僕が TDDをする理由

• テストは何かあった時の命綱o 何かあった時に命綱を編んでいては手遅れ

• 最初にテストを書くのは確かにきついo TDDはスキルなので必ず身につくo 2〜 3ヶ月もすれば慣れるo 量は質に転嫁する

とにかくやれ

TDDでよくある誤解

• TDDをやればバグがなくなる？o そんなわけない

• じゃあ TDDは意味が無い？o TDDでバグが完全になくなるわけじゃないけど、意図しないバグをほとんどつぶせる TDDをしない理由はない

• カバレッジは 100%じゃないとダメ？o あくまでテストが薄いところを見つける目安o どうして数値が低いかは確認しておくのは重要

Javaだと privateコンストラクタや catheスコープとかo 数字を上げることが目的になってはダメ

偉い人にはアピールしやすいけどネ！ｗ

参考） AZusaar!(サーバ側 ) のレポート

Line（行の網羅率） : 85%Branch（分岐の網羅率） : 91%

TDDを始めたことによる弊害

• TDD≠サービスの品質だと分かってはいても、テストがたくさんあると安心するo 安心が過信にならないように気をつけよう

• TDDを始めて 2年近くなので、呼吸をするのと同じ感覚でテストを書いているo あまり開発期間がないとは分かっていつつもテストをたくさん書いてしまう

o 全てのコードにテストを書かないと不安で仕方がないo 既に病気ｗ

テストを書くことを強いられているんだ！

グリーンバンド

• テストを書くのが辛くなった時にこれを見 て自分を戒めているらしい (by Robert C. M

artin)

• TDD BootCampの受講証・卒業証として配られることもある

act_as_professional

プロとして自分のコードに責任を持つためにテストを書くテストを書くのはプロとしての嗜み！

TDDをやりたくなったら

TDD本の定番。「ほんたった」でレッツ写経！

TDDをやりたくなったら

jsならこっちで始めるのもあり。モックの使い方が詳しい

TDDをやりたくなったら

• TDD BootCampo 終日ワークショップ（だいたい講演 +ペアプロ）o #tddbc を定点観測しておく

• TDDBC wikio http://devtesting.jp/tddbc/

• メーリングリストo http://groups.google.com/group/tddbc

• 手っ取り早く調べるなら AZusaar!がいいよ（ステマ）o http://azusaar.appspot.com/?q=tdd

おまけ

おまけ

おまけ

覚えてないんで作ったhttps://github.com/sue445/dio_tests

Have a nice Test !