Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
テスト駆動開発✅️
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
しが あきとし(akitoshiga)
October 15, 2024
Programming
940
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
テスト駆動開発✅️
テスト駆動開発について自身の実践を交えた内容とケーススタディを記載しています。
もともと社内勉強会用に作成したものですが、一般に公開させて頂くことになりました。
しが あきとし(akitoshiga)
October 15, 2024
More Decks by しが あきとし(akitoshiga)
See All by しが あきとし(akitoshiga)
雑草エンジニア
akitoshiga
5
2.6k
ケント・ベックに学ぶ『良いコード』の書き方
akitoshiga
3
760
Other Decks in Programming
See All in Programming
Intent as Code
shoppingjaws
6
1k
WebRTC映像をAirPlayに対応させる挑戦.pdf
monolithic_adam
0
260
Security issues being discussed on Web Platforms
petamoriken
0
940
Starting & Sustaining Code-Based E2E Testing for Non-Coding QA Teams( #jasstniigata )
teyamagu
PRO
1
190
iOSDC2026登壇資料.pdf
riofujimon
0
160
モジュールの視点からSwiftを読み解く #iosdc
s_shimotori
0
170
AWS Step Functions 大規模並列の壁を越える / jaws-sonic-2026-niigata-step-functions
kasacchiful
PRO
1
460
AIを上手に使っていこうとしたら越境せざるを得なくなった話 〜実践1年で見えた境界を越えなければならない理由と進め方〜 / Crossing borders with AI
tomoyakitaura
4
1.2k
そのリトライ、死んだコネクションを使い回していませんか ── GoのHTTPクライアントとHTTP/2を実プロダクト障害から学び直す
myus4a
0
140
テストを司るデーモンに会いに行く 〜隔離した仮想マシンでテストを通すまで〜
h1d3mun3
1
360
Vue Fes Japan 2026 タイムテーブル徹底解説
448jp
0
150
Go のフラットな パッケージに 「ファイル単位の private」を 〜Linter “declscope” を作った話〜
mpyw
0
320
Featured
See All Featured
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
68
57k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
250
1.3M
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.9k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
Making Projects Easy
brettharned
120
6.8k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
2.1k
Faster Mobile Websites
deanohume
310
32k
Digital Ethics as a Driver of Design Innovation
axbom
PRO
1
420
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
23k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
540
Transcript
テスト駆動開発 ✅ 2024/09/06 エンジニアリンググループ 志賀昭駿
目次 1. 概要 2. テスト駆動開発とは 3. 手順 4. 実践
1. 概要
概要 • ケント・ベックの考案したテスト駆動開発について、自身が普段実践している内容 を添えて紹介 • 本日の参加者のみなさんがテスト駆動開発について理解を深め、取り組もうと 思った時に気軽に取り組めるようになってもらう事が目的 1. 概要
2. テスト駆動開発とは
テスト駆動開発(TDD)とは • 一言で言えば、テストで設計を導く開発手法 ◦ ※ 本編で出てくる"テスト"はユニットテストを指す • "動作するきれいなコード" を実現する •
アジャイル開発手法の一つであるエクストリームプログラミング(XP)の中のプラク ティスとして、ケント・ベックが考案した「テストファースト」が源流 2. テスト駆動開発とは
テスト駆動開発のメリット 1. 認知負荷を下げて開発ができる a. 仕様をテストが担保してくれるので、実装中に脳のワーキングメモリをあまり使わなくて済む b. 複雑な制約が複数あるような機能を開発していたときに、頭のなかでそれらの整合性を考えなが ら実装しなくて済む 2. 作り込みを防ぐことが出来る
a. テストを通すという観点でコードを書くので無駄なコードを書かなくて済む 3. きれいなコードを書きやすくなる a. 仕組み上書いたコードに対してリファクタがすぐ行える b. リファクタの試行回数が多くなるので、その分きれいなコードを書きやすくなる 2. テスト駆動開発とは
テスト駆動開発のメリット 4. 実装が早くなる a. ロバート・C・マーティンは、TDDの方が常に速いと言っている b. 個人的にはTDDの方が少し速いかなと思う c. ただし先述の通りTDDはリファクタの試行回数が増えるので同じ時間でも品質に違いが出る 2.
テスト駆動開発とは
テスト駆動開発のルール 1. テストが失敗したら新しくコードを書く a. 機能・処理の実装を書く前に、必ず先に失敗するテストコードを書く 2. 重複を除去する a. 動作が保証できたら、リファクタリングを行う i.
設計判断はリファクタリングの段階で行う ii. 本来のTDDは早くテストを成功させることを重視している 2. テスト駆動開発とは
よくある質問 • テストを先に書くと開発が遅くならない? ◦ 先述の通り個人的な感覚では TDDのほうがちょっと早い ◦ ロバート・C・マーティンは常に早いと言っている • めんどくさくない?
◦ 全てを厳密なTDDのプロセスに乗っ取らなくても部分的に取り入れるのも個人的にはあり ◦ また愚直に1つ1つのテストを通さなくても状況に応じて「テストの歩幅」を変えても良い 2. テスト駆動開発とは
3. 手順
大まかな流れ(TDDサイクル) 3. 手順 画像出典 JXPRESS developer’s blog
レッド・グリーン・リファクタリング 3. 手順 • レッド ◦ 失敗するテストを書く • グリーン ◦
最低限の実装でテストを通す • リファクタリング ◦ 振る舞いを保ちつつコードを修正する
手順 3. 手順 1. チェックリスト(リスト)を用意する 2. 仕様の一つ一つをリストに追加する 3. リストの項目を選択する 4.
選択した項目にTDDサイクルを実行する 5. 項目の内容を満たしたらチェックをつける 6. 追加・変更になった仕様はリストに追加する
4. 実践
ケーススタディ レンタルビデオショップ • レンタルビデオショップの金額計算プログラムを作る • 貸出日数とビデオの種類によって金額を計算する • ビデオの種類は『一般』・『新作』・『子供向け』の三種類 • 一般の基本料金は100円で、3日目から1日あたり150円が追加される
• 新作の基本料金は300円でレンタルした日数分基本料金がかかる • 子供向けの基本料金は150円で、4日目から1日あたり150円が追加される 4. 実践 参考: Martin Fowler『リファクタリング(第 2版): 既存のコードを安全に改善する』
1. チェックリスト(リスト)を用意する • 紙でもアプリでも各自の使いやすい物でOK • 自分の場合はテストコードに先にコメントとして記述している 4. 実践
2. 仕様の一つ一つをリストに追加する • 『一般』のビデオを1日レンタルした場合は金額200円になること • 『一般』のビデオを3日レンタルした場合は金額が350円になること • 『新作』のビデオを1日レンタルした場合は金額が300円になること • 『新作』のビデオを2日レンタルした場合は金額が600円になること
• 『子供向け』のビデオを1日レンタルした場合は金額が150円になること • 『子供向け』のビデオを4日レンタルした場合は金額が300円になること 4. 実践
3. リストの項目を選択する • 始めやすくインクリメンタルに進められそうな順番で選択すればOK 4. 実践
4. 選択した項目にTDDサイクルを実行する 4. 実践
5. 項目の内容を満たしたらチェックをつける 4. 実践
6. 追加・変更になった仕様はリストに追加する • 追加・変更になった仕様に加えて、実装の過程で気付いた必要なテストケースな ども適宜追加していく 4. 実践
三角測量 • テストを一般化するための手法 • 一つしかテストケースが書かれてない機能に対して、二つ目のテストケースを追加 して、どちらのテストケースも満たすようにコードを一般化する 4. 実践
追加シナリオ 会員種別の追加 • 会員の種別という概念が追加されることになった • 種別は『一般』と『特別』の2種類 • 『特別』の場合はレンタル金額が10%オフになる 4. 実践
おまけ
個人的TDDの心がまえ • インターフェースを先に定義してテストを書くこと • 正しさ美しさの追求はあとで行うこと • テストの粒度は異なることを理解すること • テストを書きやすいコーディングを意識すること おまけ
参考書籍・Webサイト・ブログ等 • ケント・ベック「テスト駆動開発」 ◦ 今日やったことはここに全て書いてある • YouTube t-wadaさんが後世に残したい、実録レガシーコード改善 ◦ Findyさんが過去に開催されたイベントのアーカイブ
◦ 和田さんの思考過程が追えるので勉強になる • 田中ひさてる「ちょうぜつソフトウェア設計入門」 ◦ ひさてるさんが6章で実演しいてるTDDのレベルが高いのと設計の勉強にもなる • マイケル・C・フェザーズ「レガシーコード改善ガイド」 ◦ TDDではないがテストしやすいコードの書き方について勉強になる おまけ
ご清聴ありがとうございました