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
Sigma
June 23, 2021
0
580
テストに慣れてないとテスタブルなコードって
テストに慣れてないとテスタブルなコードって書けないよねという話です。
【LT募集中!】設計 モデリング LT会 - vol.2 にて登壇しました。
Sigma
June 23, 2021
Tweet
Share
More Decks by Sigma
See All by Sigma
Proxmox_VE.pdf
seiyasugimoto
0
78
Stable Diffusionで遊んでみた
seiyasugimoto
0
110
EVAフレームワーク
seiyasugimoto
0
70
SSR+SPA
seiyasugimoto
0
100
Nuxtにおける設計
seiyasugimoto
0
70
Atomic Designを ディレクトリ以外で表現
seiyasugimoto
0
67
throttleすげぇぇぇ
seiyasugimoto
0
75
スマホでPythonしたい
seiyasugimoto
0
53
平文で保存するな!
seiyasugimoto
0
80
Featured
See All Featured
BBQ
matthewcrist
78
8.7k
Being A Developer After 40
akosma
56
580k
Typedesign – Prime Four
hannesfritz
36
2k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
14
1.3k
Scaling GitHub
holman
456
140k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
101
6.6k
Bash Introduction
62gerente
604
210k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
34
8.8k
Making Projects Easy
brettharned
106
5.4k
Automating Front-end Workflow
addyosmani
1353
200k
A Tale of Four Properties
chriscoyier
150
22k
Raft: Consensus for Rubyists
vanstee
130
6.2k
Transcript
テストに慣れてないと テスタブルなコードって 書けないよねという話 テスト失敗談
しぐま Sigma • 株式会社エヌエルプラスに去年入社しました。 ◦ リファラル採用やってます! • イベント配信プラットフォームやってます。 • 現在は主にNuxtとGoとGCPを触っています。
• 一応シニアエンジニアです。
テストが益々重要になってきた • 品質が保証されていないとあらゆるコードの修正に待ったが入る ◦ ビジネスサイドとしては、利益に繋がらない目的で動いているコードを変えるということに抵抗があ る。それが許されるのは十分に品質が保証されている場合だけ。 • アジリティを保つには自動テストが必要 ◦ 素早く変更し、素早く既存部分を含めた全ての機能が動いていることを保証し、実装した機能素早く
リリースするためには自動テスト以外の方法がない。 ◦ 幸い道具は全て持っている。 • 最悪の場合動いているコードに触れるなということになる
テストコードを書けと言われるけど • テストコードの品質ってどういうことだろう • テストコードが非常に長くなってしまう • テストコードを書いているのに品質上の問題が起きている
失敗例: 長い関数に対して無理やりテストを書く • 数百行程度の長い関数に対して後からユニットテストを書こうとしたが、大量のテス トケースが必要になってしまった。 • その関数が原因と見られる不具合が発生した。テストを増やして不具合の出るパ ターンを洗い出そうとしたが既存のユニットテストが何を保証していて何を保証して いないかわからず何週間もかかってしまった。
テストしやすい詳細設計 • 関数・メソッドは短い方がいい ◦ 行数が多くif文などを多く含む関数に対してテストをすると、分岐網羅や条件網羅を達成しようとす る際に難しくなる。 ◦ 場合にもよるが20行くらいに収めたい。 • 関数・メソッドは一つのことをする方が良い
◦ テストを書いたときテストの目的が分かりやすい。
アーキテクチャに問題があるケース
バックエンドに対してE2Eテストしか書けない • コントローラに殆どのロジックが書かれている • コントローラにか書かれているロジックをテストするために、DBに値を入れ、APIを 叩いてみるテスト(E2Eテスト)しか書けない • ユニットテスト保証すべき粒度の内容がE2Eテストに書かれていて、テストコードが 分かりづらい上実行が遅い •
サービス層等を導入しサービスに対してテストを書く等
何に責務を負っているか不明瞭 • 複数の責務を負っている関数は多機能になりがちで、テストが難しくなる場合が多 い。 • 責務が不明瞭なだけでも、テストケースが何を保証しようとしているか理解すること が困難になる。 • 単一責任の原則に基づいた設計をする
めちゃくちゃな依存関係 • 依存関係が乱雑になってしまっているシステムでは、大量の関数やモジュールを モックしなければならないモック地獄になる。 • DIを採用する、責務を見直すなどして依存関係を整理
シニアエンジニアとして • テストを書いてくれないことを嘆く前に、良い設計をして設計の意図をきちんと伝え る。 • レビューの際に初心を忘れず、テストなんて分かんないよという共通の前提に立っ てレビューする。
「強くてニューゲーム」しよう!