Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
テスト駆動開発_その他編
Search
まりも
May 16, 2024
Programming
0
37
テスト駆動開発_その他編
テスト駆動開発について解説します。なるべく書籍に書いてない内容を盛り込みました。基本編に書かなかった内容となります。
まりも
May 16, 2024
Tweet
Share
More Decks by まりも
See All by まりも
メンタルモデルから見るオブジェクト設計
hrmstrsmgs
0
190
技術的負債
hrmstrsmgs
0
220
よい設計のプログラムを作るには
hrmstrsmgs
0
73
歴史から理解するJavaScript
hrmstrsmgs
0
56
論理的な考え方
hrmstrsmgs
0
56
論理的な話し合いはなぜ必要か
hrmstrsmgs
0
27
腕のある技術者はなぜ
hrmstrsmgs
0
71
疑似乱数の生成
hrmstrsmgs
0
39
構造化プログラミング
hrmstrsmgs
0
130
Other Decks in Programming
See All in Programming
複雑化したリポジトリをなんとかした話 pipenvからuvによるモノレポ構成への移行
satoshi256kbyte
1
1k
いま中途半端なSwift 6対応をするより、Default ActorやApproachable Concurrencyを有効にしてからでいいんじゃない?
yimajo
2
400
アメ車でサンノゼを走ってきたよ!
s_shimotori
0
220
Catch Up: Go Style Guide Update
andpad
0
220
iOSエンジニア向けの英語学習アプリを作る!
yukawashouhei
0
190
CSC509 Lecture 05
javiergs
PRO
0
300
バッチ処理を「状態の記録」から「事実の記録」へ
panda728
PRO
0
150
Devoxx BE - Local Development in the AI Era
kdubois
0
130
2分台で1500examples完走!爆速CIを支える環境構築術 - Kaigi on Rails 2025
falcon8823
3
3.6k
育てるアーキテクチャ:戦い抜くPythonマイクロサービスの設計と進化戦略
fujidomoe
1
170
Railsだからできる 例外業務に禍根を残さない 設定設計パターン
ei_ei_eiichi
0
470
Leading Effective Engineering Teams in the AI Era
addyosmani
1
270
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
36
6.9k
It's Worth the Effort
3n
187
28k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
A Modern Web Designer's Workflow
chriscoyier
697
190k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
114
20k
The Language of Interfaces
destraynor
162
25k
The Straight Up "How To Draw Better" Workshop
denniskardys
238
140k
Building an army of robots
kneath
306
46k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
Why Our Code Smells
bkeepers
PRO
339
57k
Balancing Empowerment & Direction
lara
4
690
Transcript
テスト駆動開発 その他編
TDDを始める
アジャイルを始める アジャ イル 2週間に一度完 成させる 顧客に見せる 顧客に常駐し てもらう 2週間単位でし か要求を受け
付けない 結果を約束し ない 個人での導入は難しいものが多い
TDDを始める 要求分析 基本設計 機能設計 詳細設計 コーディング 単体テスト システムテスト 受け入れテスト 結合テスト
要求分析 基本設計 機能設計 詳細設計 コーディング 単体テスト システムテスト ここだけで 始められる 受け入れテスト
結合テスト TDDを始める
TDDはなぜ行うか?
なぜTDDを行うか? 楽にプログラミングをしたいからです!
品質 そもそもなぜ品質は必要か?
品質 楽に生産するためですよ?
ウォーターフォール時代 要件定義 基本設計 詳細設計 実装 テスト 運用 3日 3ヶ月
アジャイル時代 設計 実装 自動単体 テスト タスク終 了 30秒 3時間
自動テスト 自動化 生産性 の向上 大変なら失敗したと思っていい
即応性 楽しさ 生産性 品質 複雑さ ウォーター フォール 開発手法
アジャイル 楽しさ 生産性 品質 複雑さ ウォーター フォール 即応性
アジャイルを使う場合のTDD
アジャイルを使う場合のTDD アジャイルでは顧客を大切にしています 2週間に一度できた機能を顧客に見せる 変更要求は積極的に受ける できれば顧客に常駐してもらう
アジャイルを使う場合のTDD • 出来るならやっていたのでは? ウォーターフォールでは顧客 を大切にしていなかった? • 無理だから断っていたのでは? 顧客の要求を全部聞いていた ら開発が炎上 •
テスト駆動開発(TDD) 機能変更が非常にやりやすい 開発手法が不可欠
TDDの呼び方
TDDと似た手法 テストファースト テスト駆動開発(TDD) 振る舞い駆動開発(BDD)
TDDと似た手法 テストファースト テスト駆動開発(TDD) 振る舞い駆動開発(BDD) どれも大体同じです
TDDの呼び方 • テストを最初にやればいいんでしょ? テストファースト • なんだかんだ言ってテスト技法なんだよね? テスト駆動開発(TDD) • 振る舞いが開発を駆動するんです!! 振る舞い駆動開発(BDD)
どれも大体同じです
レッド・グリーン・リファクタリングの特徴
テストカバレッジ
テストカバレッジ 実コード テストコード レッド なし 失敗するケースの100% グリーン 100% 成功するケースの100% リファクタリング
そのまま100% そのまま100%
テストカバレッジが100%にならない場合 テストのリファクタリング エラーになるケースが動かなくなって いるかもしれない 100%にするために必要なケースを消し ているかもしれない リファクタリングでできたクラス の単体テスト TDDの手順が使えず、ただ頑張ってテ ストを書くしかない
こちらにできたテストがあるからと元 のテストを消してしまうと100%ではな くなる可能性が
レッド・グリーン・リファクタリングの どれが一番重要か
レッド・グリーン・リファクタリングの どれが一番重要か リファクタリング • 「リファクタリングはTDDのコアだっつの」 (マーチン・ファウラー) • 設計品質に直結
レッド・グリーン・リファクタリングの どれが一番重要か レッド • 「レガシーコードとは、単にテストのない コードである」(マイケル・C・フェザーズ) • 一度足りなくなると挽回が難しい
レッド・グリーン・リファクタリングの どれが一番重要か グリーン • 大事だと特に言われてはいないが、一回でも さぼると進まないはず • 息をするように大切
レッド・グリーン・リファクタリングの どれが一番重要か 3つとも大事です!!! •大事さの意味はそれぞれ違います。 •どれが一つ欠けても成り立たない。
リファクタリング不足の対処
不足する場合 不足する場合 対処の容易性 レッド • テストを書くのをサボった • 最初から自動テストがない • サボった分だけ頑張る
• テスタビリティを考慮していなけ れば大変 グリーン • ありえない - リファクタ リング • いつの間にか • 思いつかないでいるうちに • 不足していくと加速度的に大変に • ノウハウが必要
リファクタリングの挽回方法 自動テストを十分に用意する 1行~数行の範囲で見やすく修正する 機械的にコードの重複を排除する 全体の見通しがついてきたら正しい設計に
リファクタリングの練習問題 • リファクタリングが大幅に不足したコードをリファクタリン グする練習問題をGitHubに公開してあります • 実際にリファクタリングを行う解答例も上げています • http://qiita.com/potimarimo/items/9ea1e04a1ac63c3b8d0a • https://github.com/potimarimo/practice-of-refactoring
プロジェクトへの導入
たとえ話をします。
空気の汚れた地域ですが、上空はまだきれいです。
上空を飛べば、気持ちよく飛べます。
一度下に向かうと、戻るのに苦労します。 ここが大変
下のほうを飛ぶと、ずっと大変です。
下から上に上がろうとしても、なかなか上がれません。 すごく大変
力尽きて、結局上がれないかもしれません。
いっそ本当に力尽きるかも。
これはTDD導入のたとえ話です。
TDDに必要な コード品質
最初からTDDを使って実装した場合
少しうまくいかなくても挽回の余地はある ここが大変
途中から自動テストを導入しようとした場合 すごく大変
途中から自動テストを導入しようとした場合
途中から自動テストを導入しようとした場合
途中からの導入が難しい理由 自動テストがない とリファクタリン グがやりにくい リファクタリングして ないと自動テストが書 きにくい
途中からの導入が難しい理由 自動テストを後から書く とても面倒
途中からの導入が難しい理由 自動テストを後から書く 自動化を利用できるのは最後だけ コストが減らない
結論 TDDは最初から導入しましょう せめて新機能追加のタイミングで導入 機能修正はなるべくTDDで
TDDを生み出した人たち
TDDを作った人(の一人) ケント・ベック • ケント・ベック (Kent Beck) はエクストリー ム・プログラミング (XP) の考案者でアジャイ
ルマニフェストの起草者の一人。(Wikipedia)
名言 • 僕は、偉大なプログラマなんかじゃない。偉大な習慣を身 につけたプログラマなんだ。 ケント・ベック • だが、ケントなら絶対、 何かうまい手を思い付くだろう。 マーチン・ファウラー
朝会 ミーティングは時間を かけずに行いましょう
朝会 ミーティングは時間を かけずに行いましょう ミーティングは10分で 終わりましょう
朝会 ミーティングは時間を かけずに行いましょう ミーティングは10分で 終わりましょう ミーティングは立って やりましょう
様々な工夫が凝らされている TDD ケント・ベックの 最高傑作 いろいろな 工夫が凝ら された手順
TDDは死んだのか?
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は死んだ テスティングよ栄えよ
TDD IS DEAD. LONG LIVE TESTING. テストファースト原理主義 は禁欲のみを唱えた性教育 のようなものだ。 つまり、自己嫌悪に陥って
いる人に向けた、非現実的 で効果のない、道徳教育の ようなものだ。 テストファーストのユニッ トテストは、中間的オブ ジェクトや間接的で過剰に 複雑な構造を生みがちだ。 「遅い」ものをすべて避け ようとするのがその理由で、 データベースやファイルIO などを避ける。 私はアクティブレコードを 直接、データベースをアク セスし、フィクスチャを 使ってテストする。 そう、私にとってテスト ファーストは死んだ。 テスティングよ栄えよ。
IS TDD DEAD? TDDを機能させることに 伴う犠牲は何かというこ とです。 モックをよく使う人たち はリファクタリングを難 しいと捉えるが、 自分はテストのおかげで
リファクタリングが楽に なると思うと話しました。 テストによる設計の弊害 をTDDのせいにするのは、 変な場所に車で行ったこ とを車のせいにするよう なものだと言います。 多くのビジネスでTDDが 採用されてQA部門が排除 されたと言いました。 Kentは再びQAの話題に 戻って、QA部門との関係 がうまく機能しなかった 昔の経験に言及しました。 深夜2時の電話であらか じめミスを指摘されてお く方が得策だというのが Kentの意見です。
結論 死んでません
TDDはなぜ変更に強い開発手法か
TDDはなぜ変更に強い開発手法か TDDでは、す べての機能は 機能追加とし て実装します 常に最大限変更に強く作ら ないと作業が進まない 最大限に変更容易性に気を 付けて作ることになる 変更は必ずあると考えると、
早く作ることができる
TDDの自動テストとQCテスト
TDDの自動テストとQCテスト • QCテストなどの代わりにはならない • 本質的にはQCテストのテスト理論とは関係ない • ただし、コストをかけずに大量にできる TDDで作る自動テストはユニットテストです • 単体テストが大量にあるなら、QCテストは減らしても目的は達成できる
ただし、テストの目的は総合的に品質を良くするこ と • テストとコストが比較されるので QCテストにも自動化
コードがドキュメント
コードがドキュメント コードがドキュメント 設計書を提出しろ?コードをコミットしたでしょ? あれが設計書だよ。バグまで記述してある。 なわけがないです。全然意味が違います。
コードがドキュメント テストコード 外部設計書とし て利用、保守で きる 実装コード 内部設計書とし て利用、保守で きる
コードがドキュメント 大変で すよ?
コードがドキュメント ドキュメントとして読めるコード 可読性を極限まで上げる コメントがあると邪魔なんで書くな 様々なプログラムテクニック 大変です
コードがドキュメント 設計書 コード 両方作るよりは楽
二度手間
二度手間 一見、二度手間になる作業が多い コンパイルが通らないコードを書く 動かないテストを一度は実行 一度コードを書いてからリファクタリング リファクタリングで一度作ったクラスをまた消す
二度手間 プログラムを組むときのボトルネックは手を動かすこと ではない!! ボトルネックは考えをまとめること。 考えるための手順を効率化し、考えることの二度手間 を最低限にする