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

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

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と殴り合う

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 まず、いわゆる最初に目指すべき自動テストとしては次の２つのためにテストケースを選択してください。「どのようなソフトウェアを実装しようとしているかを表現する」（定義するため）「ソフトウェアが仕様に沿っているかを表現する」（開発と詳細な仕様化のため）

31. Judgement

32. 単体テスト結合テストテストファーストテストラスト機能性構成保守性 Judgement とは言っても、どのような自動テストを導入するのか、しないのか？しないときに、どうすればいいのか？

33. 単体テストのテストファースト Not Import Unit Test テストファーストしなくても、ほとんどバグが出ないし、デバッグしやすいコードを書ける結合テストの自動化例) FizzBuzzなら単体テストからではなく、結合テストからやる。

34. 単体テストのテストファースト複数の人がその同じテストを頻繁に（1日に10回以上）繰り返すことが出来る自動化する事がそもそも難しすぎる（ツールやAPIが用意されていない、副作用が大きすぎる結合テストの自動化 Not Import Integration Test

36. Conclusion

37. テストファーストをしないのは毒を飲み続けること。忘れがちだけど大切な習慣 Conclusion テスト自動化はつらい。だけど、やらないと更につらいだけだ。勘に頼った成果物は出さないというプロ意識。普段からやらないと急になんて出来ません。

39. Reference

40. Reference(Wiki) 「テストはあとで書く」についてテストを書くメリットテストを考えた設計テストレベル入門

SlideShare for iOS

Views

Actions

Embeds 0

Report content

Transcript