Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Import Test First 
2014/11/18 
kyon_mm
Self 
Introduction 
kyon_mm 
Test Architect 
TDD/BDD Expert 
27 years old.
Agenda 
Test First 
Test Level 
Judgement 
Conclusion 
Reference
Test Last 
Automation Test Merit 
社内Wiki参照
Test Last 
社内Wiki参照 
Automation Test Merit
Agenda 
Test First 
Test Level 
Judgement 
Conclusion 
Reference
Test First
納期に間に合わなかっ 
たらどうしよう。。。 
Complicated … 
やったほうがいいのはわか 
るけど 
ベストな方法がわからな 
い 
時間もスキルもない
Important Thing 
私も、bleisさんも最初から上 
手にテストファーストを出来た 
訳でも、奇麗なテストコードを 
書けた訳でもありません。 
プライベートでも業務でも、イ 
ンプットとアウトプットをひた 
すら繰り返して、試...
弊社 
私たちの配慮不足によって相 
談しにくさもありましたが、 
「テスト可能な設計」 
「BDD」に関する知見に関し 
て、弊社は日本でも類をみな 
いほどのスキルを持った人に 
相談出来ます。 
もっと、社内全体に私やbleis 
さんの...
Step By Step 
常に検討する(やってから悩め) 
出来るところから始める 
やってはいけないことを守る
RDBなどの情報 
をもとにした、 
複雑な条件分 
岐や繰り返し 
HTTPヘッダで 
条件分岐して、 
XMLをパースし 
て、 
内容で条件分 
岐して、 
RDBにアクセス 
して、 
XMLを返す 
For Example 
内容を条...
RDBなどの情報 
をもとにした、 
複雑な条件分 
岐や繰り返し 
HTTPヘッダで 
条件分岐して、 
XMLをパースし 
て、 
内容で条件分 
岐して、 
RDBにアクセス 
して、 
XMLを返す 
For Example 
大まかな...
Mikado-Method テストファーストできない!そ 
う思ったときは、Mikado-Method 
の出番です。 
テストコードを書く難しさは、 
スキルと同じかそれ以上に、課 
題の定義や分析が不十分である 
ことが上げられます。 
そ...
Test First 
常に「まずは挑戦する」 
バランス感、スキル、リスク分 
析、戦略、レビュー、見積もり 
など 有識者と協力する。 
Test Firstを選択肢にいれな 
いっていうのは、恥ずかしい事 
です。
First Step 
1. 「テンプレートがあればテス 
トコード書ける」 
2. 「テンプレートなしでテスト 
コードを書く」 
3. 「テンプレートなしでほとん 
どのコードをテストファース 
トする」
Second Step(一人前) 
1. 「奇麗なテストコードを心が 
ける」 
2. 「いろんなテストをテストコー 
ドにする」 
3. 「いろんなテストでテスト 
ファーストする」
Third Step 
1. 真面目にテスト設計を取り入 
れたテストコードにする 
2. テスト周辺のライブラリやツー 
ルなどをカスタマイズ、自作 
する 
3. kyon_mmと殴り合う
Agenda 
Test First 
Test Level 
Judgement 
Conclusion 
Reference
Test Level
コンポーネント 
統合 
システム 
受け入れ 
ユニット 
インテグレーション 
システム 
Test Level 
テストを実行するときに動作 
させる「プロダクトの範囲」 
や「担当する責務の範囲」を 
基準に 
テストを分割する方法 
...
単体テスト 
結合テスト 
Our Unit Test 
アプリケーションの提供する 
クラスやメソッドといった 
API(内部API)を呼出し、 
想定した事象が起こるかどう 
か(期待した戻り値が返ってく 
るかなど)を確認するテスト
単体テスト 
内部APIを呼び出すことなくシ 
ステムを実際に使用し、 
想定した事象が起こるかどう 
か(正しいレスポンスが返って 
くるかや、DBの状態が正しい 
かなど)を確認するテストを結 
合テストと定義する。 
結合テスト 
Our...
Difficulty Unit Test 
「自分が作りにくいデータ構造」をどう 
やって切り離すか。 
HTTP, RDB, ファイル, 時刻 
異常系をどうやって起こすか。 
例外発生時の挙動は正しいか 
どんなテストを書けばいいのか? 
...
From My Experience 
「今までUnit Testでテストファー 
スト」していない人に関して(自信 
も含めて)経験論で言えば 
「手間を惜しんでいる」「やり方を 
変えたくない」「怠惰」なだけ。 
それ以外には存在しない。 ...
Data Structure 
「ユニットテスタビリティが高い」と言うため 
の1つの指標が「自分たちがつくっていないデー 
タ構造と切り離してテストできているか」にな 
ります。 
「テストに必要な分だけのデータ」をつくれる 
ようにする。 ...
Error Path 大抵の例外発生は結合テスト環境で動作させる 
のは難しい。単体テストの段階で例外をわざと 
起こしたテストをするのは大切です。 
例外に対処していること、異常なデータを受け 
取ったときの挙動は保証されているのか? 
スタ...
Which Test 意味のあるテストを書く事は大切です。また、 
テストコードは「ラフスケッチのように使う」 
こともあります。 
正しくいろんなAPIを呼び出せている事を確認 
するために書きます。そして、テスト対象の 
振る舞いがテストフ...
Which Test 
まず、いわゆる最初に目指すべき自動テストと 
しては次の2つのためにテストケースを選択し 
てください。 
「どのようなソフトウェアを実装しようとし 
ているかを表現する」(定義するため) 
「ソフトウェアが仕様に沿って...
Agenda 
Test First 
Test Level 
Judgement 
Conclusion 
Reference
Judgement
単体テスト 
結合テスト 
テストファースト 
テストラスト 
機能性 
構成 
保守性 
Judgement 
とは言っても、どのような自 
動テストを導入するのか、し 
ないのか? 
しないときに、どうすればい 
いのか?
単体テストのテスト 
ファースト 
Not Import Unit Test 
テストファーストしなくても、 
ほとんどバグが出ないし、デ 
バッグしやすいコードを書け 
る 
結合テストの自動化 
例) FizzBuzzなら単体テスト 
から...
単体テストのテスト 
ファースト 
複数の人がその同じテストを 
頻繁に(1日に10回以上)繰り 
返すことが出来る 
自動化する事がそもそも難し 
すぎる(ツールやAPIが用意さ 
れていない、副作用が大きす 
ぎる 
結合テストの自動化 
...
Agenda 
Test First 
Test Level 
Judgement 
Conclusion 
Reference
Conclusion
テストファーストを 
しないのは毒を飲み 
続けること。 
忘れがちだけど大切 
な習慣 
Conclusion 
テスト自動化はつらい。だけ 
ど、やらないと更につらいだ 
けだ。 
勘に頼った成果物は出さない 
というプロ意識。 
普段から...
Agenda 
Test First 
Test Level 
Judgement 
Conclusion 
Reference
Reference
Reference(Wiki) 
「テストはあとで書く」について 
テストを書くメリット 
テストを考えた設計 
テストレベル入門
Upcoming SlideShare
Loading in …5
×

テストファースト、自動テストを導入するという事について(@社内勉強会)

10,695 views

Published on

社内勉強会で「テストファーストを導入するということ」について講演しました。
社外にも公開出来るように一部改変したスライドになります。

Published in: Technology
  • Be the first to comment

テストファースト、自動テストを導入するという事について(@社内勉強会)

  1. 1. Import Test First 2014/11/18 kyon_mm
  2. 2. Self Introduction kyon_mm Test Architect TDD/BDD Expert 27 years old.
  3. 3. Agenda Test First Test Level Judgement Conclusion Reference
  4. 4. Test Last Automation Test Merit 社内Wiki参照
  5. 5. Test Last 社内Wiki参照 Automation Test Merit
  6. 6. Agenda Test First Test Level Judgement Conclusion Reference
  7. 7. Test First
  8. 8. 納期に間に合わなかっ たらどうしよう。。。 Complicated … やったほうがいいのはわか るけど ベストな方法がわからな い 時間もスキルもない
  9. 9. Important Thing 私も、bleisさんも最初から上 手にテストファーストを出来た 訳でも、奇麗なテストコードを 書けた訳でもありません。 プライベートでも業務でも、イ ンプットとアウトプットをひた すら繰り返して、試行錯誤して 少しずつ成長しました。
  10. 10. 弊社 私たちの配慮不足によって相 談しにくさもありましたが、 「テスト可能な設計」 「BDD」に関する知見に関し て、弊社は日本でも類をみな いほどのスキルを持った人に 相談出来ます。 もっと、社内全体に私やbleis さんのスキルを広めて、より よい開発に変化させていきま す。 みんなでよりよくしましょう。 (お互いに能動的になろう
  11. 11. Step By Step 常に検討する(やってから悩め) 出来るところから始める やってはいけないことを守る
  12. 12. RDBなどの情報 をもとにした、 複雑な条件分 岐や繰り返し HTTPヘッダで 条件分岐して、 XMLをパースし て、 内容で条件分 岐して、 RDBにアクセス して、 XMLを返す For Example 内容を条件分岐するところだけで もテストファーストでやる
  13. 13. RDBなどの情報 をもとにした、 複雑な条件分 岐や繰り返し HTTPヘッダで 条件分岐して、 XMLをパースし て、 内容で条件分 岐して、 RDBにアクセス して、 XMLを返す For Example 大まかな条件をまずはテストコー ドのパラメタライズとして表現し てみる
  14. 14. Mikado-Method テストファーストできない!そ う思ったときは、Mikado-Method の出番です。 テストコードを書く難しさは、 スキルと同じかそれ以上に、課 題の定義や分析が不十分である ことが上げられます。 それをサポートする「開発者用 課題発見および管理手法」です。
  15. 15. Test First 常に「まずは挑戦する」 バランス感、スキル、リスク分 析、戦略、レビュー、見積もり など 有識者と協力する。 Test Firstを選択肢にいれな いっていうのは、恥ずかしい事 です。
  16. 16. First Step 1. 「テンプレートがあればテス トコード書ける」 2. 「テンプレートなしでテスト コードを書く」 3. 「テンプレートなしでほとん どのコードをテストファース トする」
  17. 17. Second Step(一人前) 1. 「奇麗なテストコードを心が ける」 2. 「いろんなテストをテストコー ドにする」 3. 「いろんなテストでテスト ファーストする」
  18. 18. Third Step 1. 真面目にテスト設計を取り入 れたテストコードにする 2. テスト周辺のライブラリやツー ルなどをカスタマイズ、自作 する 3. kyon_mmと殴り合う
  19. 19. Agenda Test First Test Level Judgement Conclusion Reference
  20. 20. Test Level
  21. 21. コンポーネント 統合 システム 受け入れ ユニット インテグレーション システム Test Level テストを実行するときに動作 させる「プロダクトの範囲」 や「担当する責務の範囲」を 基準に テストを分割する方法 分割したテストの総称
  22. 22. 単体テスト 結合テスト Our Unit Test アプリケーションの提供する クラスやメソッドといった API(内部API)を呼出し、 想定した事象が起こるかどう か(期待した戻り値が返ってく るかなど)を確認するテスト
  23. 23. 単体テスト 内部APIを呼び出すことなくシ ステムを実際に使用し、 想定した事象が起こるかどう か(正しいレスポンスが返って くるかや、DBの状態が正しい かなど)を確認するテストを結 合テストと定義する。 結合テスト Our Integration Test
  24. 24. Difficulty Unit Test 「自分が作りにくいデータ構造」をどう やって切り離すか。 HTTP, RDB, ファイル, 時刻 異常系をどうやって起こすか。 例外発生時の挙動は正しいか どんなテストを書けばいいのか? 書く必要があるのか?書かないとダメ なやつは何か?
  25. 25. From My Experience 「今までUnit Testでテストファー スト」していない人に関して(自信 も含めて)経験論で言えば 「手間を惜しんでいる」「やり方を 変えたくない」「怠惰」なだけ。 それ以外には存在しない。 常にそうやってがんばることで、品 質と進捗に貢献出来る。
  26. 26. Data Structure 「ユニットテスタビリティが高い」と言うため の1つの指標が「自分たちがつくっていないデー タ構造と切り離してテストできているか」にな ります。 「テストに必要な分だけのデータ」をつくれる ようにする。 抽象クラスやインターフェース経由 データ構造を「ドメイン」や「テストしたい 単位」に詰め替える(BDDをすると自然にだい たい一緒になる)
  27. 27. Error Path 大抵の例外発生は結合テスト環境で動作させる のは難しい。単体テストの段階で例外をわざと 起こしたテストをするのは大切です。 例外に対処していること、異常なデータを受け 取ったときの挙動は保証されているのか? スタブやアダプタクラスをつかって、異常系 を発生させる。 「そのテストは一部が本物のコードじゃない ですよね?」→「テストしていないコードと どっちが信頼高いんですか?」「テスト対象 が違う」
  28. 28. Which Test 意味のあるテストを書く事は大切です。また、 テストコードは「ラフスケッチのように使う」 こともあります。 正しくいろんなAPIを呼び出せている事を確認 するために書きます。そして、テスト対象の 振る舞いがテストファーストによって様々な コードによって網羅されれば、最初のテスト コードは不要になります。削除します。 「リリースに必要なコード」と「そのときに必 要なコード」は一致しません。だからといって、 「そのときに必要なコード」を実装しないこと は品質と進捗に悪影響を及ぼします。つまり、 手抜きです。
  29. 29. Which Test まず、いわゆる最初に目指すべき自動テストと しては次の2つのためにテストケースを選択し てください。 「どのようなソフトウェアを実装しようとし ているかを表現する」(定義するため) 「ソフトウェアが仕様に沿っているかを表現 する」(開発と詳細な仕様化のため)
  30. 30. Agenda Test First Test Level Judgement Conclusion Reference
  31. 31. Judgement
  32. 32. 単体テスト 結合テスト テストファースト テストラスト 機能性 構成 保守性 Judgement とは言っても、どのような自 動テストを導入するのか、し ないのか? しないときに、どうすればい いのか?
  33. 33. 単体テストのテスト ファースト Not Import Unit Test テストファーストしなくても、 ほとんどバグが出ないし、デ バッグしやすいコードを書け る 結合テストの自動化 例) FizzBuzzなら単体テスト からではなく、結合テストか らやる。
  34. 34. 単体テストのテスト ファースト 複数の人がその同じテストを 頻繁に(1日に10回以上)繰り 返すことが出来る 自動化する事がそもそも難し すぎる(ツールやAPIが用意さ れていない、副作用が大きす ぎる 結合テストの自動化 Not Import Integration Test
  35. 35. Agenda Test First Test Level Judgement Conclusion Reference
  36. 36. Conclusion
  37. 37. テストファーストを しないのは毒を飲み 続けること。 忘れがちだけど大切 な習慣 Conclusion テスト自動化はつらい。だけ ど、やらないと更につらいだ けだ。 勘に頼った成果物は出さない というプロ意識。 普段からやらないと急になん て出来ません。
  38. 38. Agenda Test First Test Level Judgement Conclusion Reference
  39. 39. Reference
  40. 40. Reference(Wiki) 「テストはあとで書く」について テストを書くメリット テストを考えた設計 テストレベル入門

×