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
290
テストを書いた方が良いところ 書かなくても良いところ
CAMPHOR- DAY 2019のLT用資料です。
https://camphor.connpass.com/event/119434/
ぷらす
March 09, 2019
Tweet
Share
More Decks by ぷらす
See All by ぷらす
AWSの認定資格を受けた話
p1ass
1
440
趣味プロジェクトをリードする技術 / 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
83
ドメインロジックと 永続化処理を分離する設計改善 を行って得られた知見 / Design improvements that separate domain logic and persistence function
p1ass
1
2.1k
Other Decks in Technology
See All in Technology
小さなチーム 大きな仕事 - 個人開発でAIをフル活用する
himaratsu
0
120
Browser
recruitengineers
PRO
3
290
モダンな現場と従来型の組織——そこに生じる "不整合" を解消してこそチームがパフォーマンスを発揮できる / Team-oriented Organization Design 20250825
mtx2s
5
530
AIエージェント就活入門 - MCPが履歴書になる未来
eltociear
0
470
退屈なことはDevinにやらせよう〜〜Devin APIを使ったVisual Regression Testの自動追加〜
kawamataryo
2
280
開発と脆弱性と脆弱性診断についての話
su3158
1
1.1k
トヨタ生産方式(TPS)入門
recruitengineers
PRO
2
220
実践データベース設計 ①データベース設計概論
recruitengineers
PRO
2
210
JuniorからSeniorまで: DevOpsエンジニアの成長ロードマップ
yuriemori
0
110
モバイルアプリ研修
recruitengineers
PRO
2
240
KiroでGameDay開催してみよう(準備編)
yuuuuuuu168
1
130
Postman MCP 関連機能アップデート / Postman MCP feature updates
yokawasa
0
150
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
184
22k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
BBQ
matthewcrist
89
9.8k
It's Worth the Effort
3n
187
28k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
110
20k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.5k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Designing for Performance
lara
610
69k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
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