テスト駆動開発_その他編

テスト駆動開発について解説します。なるべく書籍に書いてない内容を盛り込みました。基本編に書かなかった内容となります。

Transcript

1. テスト駆動開発 その他編
2. TDDを始める
3. アジャイルを始める アジャ イル 2週間に一度完 成させる 顧客に見せる 顧客に常駐し てもらう 2週間単位でし か要求を受け 付けない 結果を約束し ない 個人での導入は難しいものが多い
4. TDDを始める 要求分析 基本設計 機能設計 詳細設計 コーディング 単体テスト システムテスト 受け入れテスト 結合テスト
5. 要求分析 基本設計 機能設計 詳細設計 コーディング 単体テスト システムテスト ここだけで 始められる 受け入れテスト 結合テスト TDDを始める
6. TDDはなぜ行うか？
7. なぜTDDを行うか？ 楽にプログラミングをしたいからです！
8. 品質 そもそもなぜ品質は必要か？
9. 品質 楽に生産するためですよ？
10. ウォーターフォール時代 要件定義 基本設計 詳細設計 実装 テスト 運用 ３日 3ヶ月
11. アジャイル時代 設計 実装 自動単体 テスト タスク終 了 30秒 ３時間
12. 自動テスト 自動化 生産性 の向上 大変なら失敗したと思っていい
13. 即応性 楽しさ 生産性 品質 複雑さ ウォーター フォール 開発手法
14. アジャイル 楽しさ 生産性 品質 複雑さ ウォーター フォール 即応性
15. アジャイルを使う場合のTDD
16. アジャイルを使う場合のTDD アジャイルでは顧客を大切にしています 2週間に一度できた機能を顧客に見せる 変更要求は積極的に受ける できれば顧客に常駐してもらう
17. アジャイルを使う場合のTDD • 出来るならやっていたのでは？ ウォーターフォールでは顧客 を大切にしていなかった？ • 無理だから断っていたのでは？ 顧客の要求を全部聞いていた ら開発が炎上 • テスト駆動開発(TDD) 機能変更が非常にやりやすい 開発手法が不可欠
18. TDDの呼び方
19. TDDと似た手法 テストファースト テスト駆動開発(TDD) 振る舞い駆動開発(BDD)
20. TDDと似た手法 テストファースト テスト駆動開発(TDD) 振る舞い駆動開発(BDD) どれも大体同じです
21. TDDの呼び方 • テストを最初にやればいいんでしょ？ テストファースト • なんだかんだ言ってテスト技法なんだよね？ テスト駆動開発(TDD) • 振る舞いが開発を駆動するんです！！ 振る舞い駆動開発(BDD) どれも大体同じです
22. レッド・グリーン・リファクタリングの特徴
23. テストカバレッジ
24. テストカバレッジ 実コード テストコード レッド なし 失敗するケースの100% グリーン 100% 成功するケースの100% リファクタリング そのまま100% そのまま100%
25. テストカバレッジが100%にならない場合 テストのリファクタリング エラーになるケースが動かなくなって いるかもしれない 100%にするために必要なケースを消し ているかもしれない リファクタリングでできたクラス の単体テスト TDDの手順が使えず、ただ頑張ってテ ストを書くしかない こちらにできたテストがあるからと元 のテストを消してしまうと100%ではな くなる可能性が
26. レッド・グリーン・リファクタリングの どれが一番重要か
27. レッド・グリーン・リファクタリングの どれが一番重要か リファクタリング • 「リファクタリングはTDDのコアだっつの」 (マーチン・ファウラー) • 設計品質に直結
28. レッド・グリーン・リファクタリングの どれが一番重要か レッド • 「レガシーコードとは、単にテストのない コードである」(マイケル・Ｃ・フェザーズ) • 一度足りなくなると挽回が難しい
29. レッド・グリーン・リファクタリングの どれが一番重要か グリーン • 大事だと特に言われてはいないが、一回でも さぼると進まないはず • 息をするように大切
30. レッド・グリーン・リファクタリングの どれが一番重要か 3つとも大事です!!! •大事さの意味はそれぞれ違います。 •どれが一つ欠けても成り立たない。
31. リファクタリング不足の対処
32. 不足する場合 不足する場合 対処の容易性 レッド • テストを書くのをサボった • 最初から自動テストがない • サボった分だけ頑張る • テスタビリティを考慮していなけ れば大変 グリーン • ありえない - リファクタ リング • いつの間にか • 思いつかないでいるうちに • 不足していくと加速度的に大変に • ノウハウが必要
33. リファクタリングの挽回方法 自動テストを十分に用意する 1行～数行の範囲で見やすく修正する 機械的にコードの重複を排除する 全体の見通しがついてきたら正しい設計に
34. リファクタリングの練習問題 • リファクタリングが大幅に不足したコードをリファクタリン グする練習問題をGitHubに公開してあります • 実際にリファクタリングを行う解答例も上げています • http://qiita.com/potimarimo/items/9ea1e04a1ac63c3b8d0a • https://github.com/potimarimo/practice-of-refactoring
35. プロジェクトへの導入
36. たとえ話をします。
37. 空気の汚れた地域ですが、上空はまだきれいです。
38. 上空を飛べば、気持ちよく飛べます。
39. 一度下に向かうと、戻るのに苦労します。 ここが大変
40. 下のほうを飛ぶと、ずっと大変です。
41. 下から上に上がろうとしても、なかなか上がれません。 すごく大変
42. 力尽きて、結局上がれないかもしれません。
43. いっそ本当に力尽きるかも。
44. これはTDD導入のたとえ話です。
45. ＴＤＤに必要な コード品質
46. 最初からTDDを使って実装した場合
47. 少しうまくいかなくても挽回の余地はある ここが大変
48. 途中から自動テストを導入しようとした場合 すごく大変
49. 途中から自動テストを導入しようとした場合
50. 途中から自動テストを導入しようとした場合
51. 途中からの導入が難しい理由 自動テストがない とリファクタリン グがやりにくい リファクタリングして ないと自動テストが書 きにくい
52. 途中からの導入が難しい理由 自動テストを後から書く とても面倒
53. 途中からの導入が難しい理由 自動テストを後から書く 自動化を利用できるのは最後だけ コストが減らない
54. 結論 TDDは最初から導入しましょう せめて新機能追加のタイミングで導入 機能修正はなるべくTDDで
55. TDDを生み出した人たち
56. TDDを作った人（の一人） ケント・ベック • ケント・ベック (Kent Beck) はエクストリー ム・プログラミング (XP) の考案者でアジャイ ルマニフェストの起草者の一人。(Wikipedia)
57. 名言 • 僕は、偉大なプログラマなんかじゃない。偉大な習慣を身 につけたプログラマなんだ。 ケント・ベック • だが、ケントなら絶対、 何かうまい手を思い付くだろう。 マーチン・ファウラー
58. 朝会 ミーティングは時間を かけずに行いましょう
59. 朝会 ミーティングは時間を かけずに行いましょう ミーティングは10分で 終わりましょう
60. 朝会 ミーティングは時間を かけずに行いましょう ミーティングは10分で 終わりましょう ミーティングは立って やりましょう
61. 様々な工夫が凝らされている TDD ケント・ベックの 最高傑作 いろいろな 工夫が凝ら された手順
62. TDDは死んだのか？
63. TDD IS DEAD AND LONG LIVE TESTING •2014年 •David Heinemeier Hansson(DHH) • TDD is dead. Long live testing. • TDD is dead. Long live testing.(日本語訳) • Is TDD Dead? • Is TDD Dead?(日本語訳) TDDは死んだ テスティングよ栄えよ
64. TDD IS DEAD. LONG LIVE TESTING. テストファースト原理主義 は禁欲のみを唱えた性教育 のようなものだ。 つまり、自己嫌悪に陥って いる人に向けた、非現実的 で効果のない、道徳教育の ようなものだ。 テストファーストのユニッ トテストは、中間的オブ ジェクトや間接的で過剰に 複雑な構造を生みがちだ。 「遅い」ものをすべて避け ようとするのがその理由で、 データベースやファイルIO などを避ける。 私はアクティブレコードを 直接、データベースをアク セスし、フィクスチャを 使ってテストする。 そう、私にとってテスト ファーストは死んだ。 テスティングよ栄えよ。
65. IS TDD DEAD? TDDを機能させることに 伴う犠牲は何かというこ とです。 モックをよく使う人たち はリファクタリングを難 しいと捉えるが、 自分はテストのおかげで リファクタリングが楽に なると思うと話しました。 テストによる設計の弊害 をTDDのせいにするのは、 変な場所に車で行ったこ とを車のせいにするよう なものだと言います。 多くのビジネスでTDDが 採用されてQA部門が排除 されたと言いました。 Kentは再びQAの話題に 戻って、QA部門との関係 がうまく機能しなかった 昔の経験に言及しました。 深夜2時の電話であらか じめミスを指摘されてお く方が得策だというのが Kentの意見です。
66. 結論 死んでません
67. TDDはなぜ変更に強い開発手法か
68. TDDはなぜ変更に強い開発手法か TDDでは、す べての機能は 機能追加とし て実装します 常に最大限変更に強く作ら ないと作業が進まない 最大限に変更容易性に気を 付けて作ることになる 変更は必ずあると考えると、 早く作ることができる
69. TDDの自動テストとQCテスト
70. TDDの自動テストとQCテスト • QCテストなどの代わりにはならない • 本質的にはQCテストのテスト理論とは関係ない • ただし、コストをかけずに大量にできる TDDで作る自動テストはユニットテストです • 単体テストが大量にあるなら、QCテストは減らしても目的は達成できる ただし、テストの目的は総合的に品質を良くするこ と • テストとコストが比較されるので QCテストにも自動化
71. コードがドキュメント
72. コードがドキュメント コードがドキュメント 設計書を提出しろ？コードをコミットしたでしょ？ あれが設計書だよ。バグまで記述してある。 なわけがないです。全然意味が違います。
73. コードがドキュメント テストコード 外部設計書とし て利用、保守で きる 実装コード 内部設計書とし て利用、保守で きる
74. コードがドキュメント 大変で すよ？
75. コードがドキュメント ドキュメントとして読めるコード 可読性を極限まで上げる コメントがあると邪魔なんで書くな 様々なプログラムテクニック 大変です
76. コードがドキュメント 設計書 コード 両方作るよりは楽
77. 二度手間
78. 二度手間 一見、二度手間になる作業が多い コンパイルが通らないコードを書く 動かないテストを一度は実行 一度コードを書いてからリファクタリング リファクタリングで一度作ったクラスをまた消す
79. 二度手間 プログラムを組むときのボトルネックは手を動かすこと ではない!! ボトルネックは考えをまとめること。 考えるための手順を効率化し、考えることの二度手間 を最低限にする