$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
テストに慣れてないとテスタブルなコードって
Search
Sigma
June 23, 2021
1
780
テストに慣れてないとテスタブルなコードって
テストに慣れてないとテスタブルなコードって書けないよねという話です。
【LT募集中!】設計 モデリング LT会 - vol.2 にて登壇しました。
Sigma
June 23, 2021
Tweet
Share
More Decks by Sigma
See All by Sigma
Proxmox_VE.pdf
seiyasugimoto
0
200
Stable Diffusionで遊んでみた
seiyasugimoto
1
130
EVAフレームワーク
seiyasugimoto
0
110
SSR+SPA
seiyasugimoto
0
130
Nuxtにおける設計
seiyasugimoto
0
89
Atomic Designを ディレクトリ以外で表現
seiyasugimoto
0
80
throttleすげぇぇぇ
seiyasugimoto
0
78
スマホでPythonしたい
seiyasugimoto
0
66
平文で保存するな!
seiyasugimoto
0
87
Featured
See All Featured
Visualization
eitanlees
150
16k
How STYLIGHT went responsive
nonsquared
100
5.9k
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
1
70
Code Review Best Practice
trishagee
73
19k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
10
700
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
36
6.2k
Designing for Performance
lara
610
69k
Building Adaptive Systems
keathley
44
2.9k
Faster Mobile Websites
deanohume
310
31k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.2k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.7k
Done Done
chrislema
186
16k
Transcript
テストに慣れてないと テスタブルなコードって 書けないよねという話 テスト失敗談
しぐま Sigma • 株式会社エヌエルプラスに去年入社しました。 ◦ リファラル採用やってます! • イベント配信プラットフォームやってます。 • 現在は主にNuxtとGoとGCPを触っています。
• 一応シニアエンジニアです。
テストが益々重要になってきた • 品質が保証されていないとあらゆるコードの修正に待ったが入る ◦ ビジネスサイドとしては、利益に繋がらない目的で動いているコードを変えるということに抵抗があ る。それが許されるのは十分に品質が保証されている場合だけ。 • アジリティを保つには自動テストが必要 ◦ 素早く変更し、素早く既存部分を含めた全ての機能が動いていることを保証し、実装した機能素早く
リリースするためには自動テスト以外の方法がない。 ◦ 幸い道具は全て持っている。 • 最悪の場合動いているコードに触れるなということになる
テストコードを書けと言われるけど • テストコードの品質ってどういうことだろう • テストコードが非常に長くなってしまう • テストコードを書いているのに品質上の問題が起きている
失敗例: 長い関数に対して無理やりテストを書く • 数百行程度の長い関数に対して後からユニットテストを書こうとしたが、大量のテス トケースが必要になってしまった。 • その関数が原因と見られる不具合が発生した。テストを増やして不具合の出るパ ターンを洗い出そうとしたが既存のユニットテストが何を保証していて何を保証して いないかわからず何週間もかかってしまった。
テストしやすい詳細設計 • 関数・メソッドは短い方がいい ◦ 行数が多くif文などを多く含む関数に対してテストをすると、分岐網羅や条件網羅を達成しようとす る際に難しくなる。 ◦ 場合にもよるが20行くらいに収めたい。 • 関数・メソッドは一つのことをする方が良い
◦ テストを書いたときテストの目的が分かりやすい。
アーキテクチャに問題があるケース
バックエンドに対してE2Eテストしか書けない • コントローラに殆どのロジックが書かれている • コントローラにか書かれているロジックをテストするために、DBに値を入れ、APIを 叩いてみるテスト(E2Eテスト)しか書けない • ユニットテスト保証すべき粒度の内容がE2Eテストに書かれていて、テストコードが 分かりづらい上実行が遅い •
サービス層等を導入しサービスに対してテストを書く等
何に責務を負っているか不明瞭 • 複数の責務を負っている関数は多機能になりがちで、テストが難しくなる場合が多 い。 • 責務が不明瞭なだけでも、テストケースが何を保証しようとしているか理解すること が困難になる。 • 単一責任の原則に基づいた設計をする
めちゃくちゃな依存関係 • 依存関係が乱雑になってしまっているシステムでは、大量の関数やモジュールを モックしなければならないモック地獄になる。 • DIを採用する、責務を見直すなどして依存関係を整理
シニアエンジニアとして • テストを書いてくれないことを嘆く前に、良い設計をして設計の意図をきちんと伝え る。 • レビューの際に初心を忘れず、テストなんて分かんないよという共通の前提に立っ てレビューする。
「強くてニューゲーム」しよう!