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