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
73
ドメインロジックと 永続化処理を分離する設計改善 を行って得られた知見 / Design improvements that separate domain logic and persistence function
p1ass
1
2.1k
Other Decks in Technology
See All in Technology
declaration mergingの威力:ライブラリアップデート時の書き換え作業を90%短縮するテクニック
yutake27
2
250
Cloud Run を解剖して コンテナ監視を考える / Breaking Down Cloud Run to Rethink Container Monitoring
aoto
PRO
0
110
AIのための オンボーディングドキュメントを整備する - hirotea
hirotea
9
2k
All About Sansan – for New Global Engineers
sansan33
PRO
1
1.2k
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
17k
初めてのGoogle Cloud by AWS出身者
harukasakihara
1
720
mnt_data_とは?ChatGPTコード実行環境を深堀りしてみた
icck
0
130
Project Referencesを活用した実行環境ごとのtsconfig最適化
itatchi3
1
240
新卒から4年間、20年もののWebサービスと向き合って学んだソフトウェア考古学 - PHPカンファレンス新潟2025 / new graduate 4year software archeology
oguri
2
310
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
24k
Contract One Dev Group 紹介資料
sansan33
PRO
0
5.8k
変化に強いテーブル設計の勘所 / Table design that is resistant to changes
soudai
PRO
50
13k
Featured
See All Featured
Reflections from 52 weeks, 52 projects
jeffersonlam
349
20k
A Tale of Four Properties
chriscoyier
159
23k
Visualization
eitanlees
146
16k
Navigating Team Friction
lara
185
15k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
42
2.3k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
6
650
Embracing the Ebb and Flow
colly
85
4.7k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Making Projects Easy
brettharned
116
6.2k
BBQ
matthewcrist
88
9.6k
Statistics for Hackers
jakevdp
799
220k
A Modern Web Designer's Workflow
chriscoyier
693
190k
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