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
260
テストを書いた方が良いところ 書かなくても良いところ
CAMPHOR- DAY 2019のLT用資料です。
https://camphor.connpass.com/event/119434/
ぷらす
March 09, 2019
Tweet
Share
More Decks by ぷらす
See All by ぷらす
AWSの認定資格を受けた話
p1ass
1
380
趣味プロジェクトをリードする技術 / Technology to lead hobby projects
p1ass
21
8.8k
vercel/og-imageを使ったブログOGPの簡単自動生成 / Generate OGP easily using vercel og-image
p1ass
2
1.3k
Webアプリケーションにおける並行処理の難しさ / #Gocon_Sendai
p1ass
4
2.5k
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.6k
Kubernetesのイメージタグの更新を楽にするツールを作った / p1ass/mikku - make updating Kubernetes image tags easier
p1ass
1
62
ドメインロジックと 永続化処理を分離する設計改善 を行って得られた知見 / Design improvements that separate domain logic and persistence function
p1ass
1
2k
Other Decks in Technology
See All in Technology
Perlの生きのこり - エンジニアがこの先生きのこるためのカンファレンス2025
kfly8
2
270
JAWS FESTA 2024「バスロケ」GPS×サーバーレスの開発と運用の舞台裏/jawsfesta2024-bus-gps-serverless
ma2shita
3
200
実は強い 非ViTな画像認識モデル
tattaka
3
1.3k
OSS構成管理ツールCMDBuildを使ったAWSリソース管理の自動化
satorufunai
0
650
RayでPHPのデバッグをちょっと快適にする
muno92
PRO
0
190
スキルだけでは満たせない、 “組織全体に”なじむオンボーディング/Onboarding that fits “throughout the organization” and cannot be satisfied by skills alone
bitkey
0
180
設計を積み重ねてシステムを刷新する
sansantech
PRO
0
170
Pwned Labsのすゝめ
ken5scal
2
440
Windows の新しい管理者保護モード
murachiakira
0
200
あなたが人生で成功するための5つの普遍的法則 #jawsug #jawsdays2025 / 20250301 HEROZ
yoshidashingo
2
290
【詳説】コンテンツ配信 システムの複数機能 基盤への拡張
hatena
0
260
依存パッケージの更新はコツコツが勝つコツ! / phpcon_nagoya2025
blue_goheimochi
3
220
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
461
33k
The Pragmatic Product Professional
lauravandoore
32
6.4k
Navigating Team Friction
lara
183
15k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
12
990
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
10
1.3k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Designing for humans not robots
tammielis
250
25k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
10
510
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.2k
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.3k
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