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
ぷらす
March 09, 2019
Technology
2
280
テストを書いた方が良いところ 書かなくても良いところ
CAMPHOR- DAY 2019のLT用資料です。
https://camphor.connpass.com/event/119434/
ぷらす
March 09, 2019
Tweet
Share
More Decks by ぷらす
See All by ぷらす
AWSの認定資格を受けた話
p1ass
1
410
趣味プロジェクトをリードする技術 / Technology to lead hobby projects
p1ass
21
8.9k
vercel/og-imageを使ったブログOGPの簡単自動生成 / Generate OGP easily using vercel og-image
p1ass
2
1.3k
Webアプリケーションにおける並行処理の難しさ / #Gocon_Sendai
p1ass
4
2.6k
RSSフィードをもっと便利に / Make RSS feeds more convenient #camphor_lt
p1ass
1
15k
うじまる君の生活習慣の乱れを可視化したい! / uzimaru birthday LT
p1ass
2
16k
複数サービスを運用しやすい理想のコンテナ環境をVPS上に構築する #camphor_day / Building ideal container environment on VPS
p1ass
1
8.7k
Kubernetesのイメージタグの更新を楽にするツールを作った / p1ass/mikku - make updating Kubernetes image tags easier
p1ass
1
77
ドメインロジックと 永続化処理を分離する設計改善 を行って得られた知見 / Design improvements that separate domain logic and persistence function
p1ass
1
2.1k
Other Decks in Technology
See All in Technology
生成AIをテストプロセスに活用し"よう"としている話 #jasstnano
makky_tyuyan
0
250
25分で解説する「最小権限の原則」を実現するための AWS「ポリシー」大全
opelab
6
1.6k
TerraformをSaaSで使うとAzureの運用がこんなに楽ちん!HCP Terraformって何?
mnakabayashi
0
290
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
4
1.2k
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
52
31k
監視のこれまでとこれから/sakura monitoring seminar 2025
fujiwara3
10
2.5k
新規プロダクト開発、AIでどう変わった? #デザインエンジニアMeetup
bengo4com
0
490
CSS、JSをHTMLテンプレートにまとめるフロントエンド戦略
d120145
0
180
DroidKnights 2025 - Jetpack XR 살펴보기: XR 개발은 어떻게 이루어지는가?
heesung6701
1
150
20250623 Findy Lunch LT Brown
3150
0
690
「どこにある?」の解決。生成AI(RAG)で効率化するガバメントクラウド運用
toru_kubota
2
460
Azure AI Foundryでマルチエージェントワークフロー
seosoft
0
130
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.3k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
Embracing the Ebb and Flow
colly
86
4.7k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
16
930
Large-scale JavaScript Application Architecture
addyosmani
512
110k
What's in a price? How to price your products and services
michaelherold
245
12k
Side Projects
sachag
455
42k
Producing Creativity
orderedlist
PRO
346
40k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
4
190
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Transcript
テストを書いた方が良いところ 書かなくても良いところ 2019/3/9 CAMPHOR- DAY 2019 京都大学 岸 直輝
テストコード書いてますか?
自己紹介 • 岸 直輝 (@plus_kyoto) • 京都大学 工学部 電気電子工学科 2回生
• サーバーサイドの人 (GolangとかPythonとか) • インターンでJava書いてる @ 東京
Q. 何のためにテストを書く?
A. 正しく動作するか確認するため
でもたくさんテストを 書く時間がないよ
どこの部分をテストしたら いいか分からない
大事なこと 動作をきちんと確認したい ところからテストを書いていく
例えば
DBアクセス ☑ CRUDが正しく動作しているか? ☑ 正しいSQLが発行できているか? (JOIN etc.) モックに差し替えられがちで 上のレイヤーのテストでバグが発見されにくい RepositoryとかDAOとか言う部分
認証周り サインインやサインアップ処理 セキュリティチェックは大事! ☑ バリデーションチェックされているか? ☑ 権限に応じたパーミッションが設定されているか?
例外処理 正常系よりも異常系の方が複雑になりがち ☑ 0やnull時の挙動 はチェックしたか?(ヌルポ) ☑ 内部エラーとレスポンスが一致しているか?
逆に書かなくてもいいこともある
ライブラリのラッパー • 有名なOSSなどはしっかりテストが書かれている • 単にライブラリのAPIを呼ぶだけのコードを テストする意味はない テストの重複は時間の無駄
複数から呼ばれる単純な処理 • コード = 仕様 レベルの単純な処理 • バグってても、呼び出し元のテストが 落ちるのでバグ検出可能 ただし、複雑な処理の場合は
原因切り分けのために、テストを書いた方が良さげ
まとめ
まとめ • モック化される部分のテストは書こう • ないがしろにしがちな例外処理はきちんと確認しよう • テストを書かなくてもいい部分があると認識しよう テストを書いてバグにハマらない 快適なコーディング生活を
Thank you Twitter : @plus_kyoto GitHub : naoki-kishi