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
64
ドメインロジックと 永続化処理を分離する設計改善 を行って得られた知見 / Design improvements that separate domain logic and persistence function
p1ass
1
2k
Other Decks in Technology
See All in Technology
実は強い 非ViTな画像認識モデル
tattaka
3
1.4k
EDRの検知の仕組みと検知回避について
chayakonanaika
12
5.2k
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
19k
AWSではじめる Web APIテスト実践ガイド / A practical guide to testing Web APIs on AWS
yokawasa
8
760
日経のデータベース事業とElasticsearch
hinatades
PRO
0
260
OPENLOGI Company Profile for engineer
hr01
1
20k
1行のコードから社会課題の解決へ: EMの探究、事業・技術・組織を紡ぐ実践知 / EM Conf 2025
9ma3r
12
4.5k
Introduction to OpenSearch Project - Search Engineering Tech Talk 2025 Winter
tkykenmt
2
170
Amazon Athenaから利用時のGlueのIcebergテーブルのメンテナンスについて
nayuts
0
110
プルリクエストレビューを終わらせるためのチーム体制 / The Team for Completing Pull Request Reviews
nekonenene
1
270
エンジニア主導の企画立案を可能にする組織とは?
recruitengineers
PRO
1
280
事業モメンタムを生み出すプロダクト開発
macchiitaka
0
100
Featured
See All Featured
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
The Cult of Friendly URLs
andyhume
78
6.2k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.4k
Large-scale JavaScript Application Architecture
addyosmani
511
110k
Side Projects
sachag
452
42k
Mobile First: as difficult as doing things right
swwweet
223
9.5k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
366
25k
How to Ace a Technical Interview
jacobian
276
23k
Building Applications with DynamoDB
mza
93
6.2k
Designing for Performance
lara
605
68k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.6k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
46
2.4k
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