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
740
テストに慣れてないとテスタブルなコードって
テストに慣れてないとテスタブルなコードって書けないよねという話です。
【LT募集中!】設計 モデリング LT会 - vol.2 にて登壇しました。
Sigma
June 23, 2021
Tweet
Share
More Decks by Sigma
See All by Sigma
Proxmox_VE.pdf
seiyasugimoto
0
190
Stable Diffusionで遊んでみた
seiyasugimoto
1
130
EVAフレームワーク
seiyasugimoto
0
100
SSR+SPA
seiyasugimoto
0
130
Nuxtにおける設計
seiyasugimoto
0
88
Atomic Designを ディレクトリ以外で表現
seiyasugimoto
0
79
throttleすげぇぇぇ
seiyasugimoto
0
77
スマホでPythonしたい
seiyasugimoto
0
66
平文で保存するな!
seiyasugimoto
0
87
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
Code Reviewing Like a Champion
maltzj
524
40k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.6k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
820
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
730
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Navigating Team Friction
lara
187
15k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
The Invisible Side of Design
smashingmag
301
51k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Transcript
テストに慣れてないと テスタブルなコードって 書けないよねという話 テスト失敗談
しぐま Sigma • 株式会社エヌエルプラスに去年入社しました。 ◦ リファラル採用やってます! • イベント配信プラットフォームやってます。 • 現在は主にNuxtとGoとGCPを触っています。
• 一応シニアエンジニアです。
テストが益々重要になってきた • 品質が保証されていないとあらゆるコードの修正に待ったが入る ◦ ビジネスサイドとしては、利益に繋がらない目的で動いているコードを変えるということに抵抗があ る。それが許されるのは十分に品質が保証されている場合だけ。 • アジリティを保つには自動テストが必要 ◦ 素早く変更し、素早く既存部分を含めた全ての機能が動いていることを保証し、実装した機能素早く
リリースするためには自動テスト以外の方法がない。 ◦ 幸い道具は全て持っている。 • 最悪の場合動いているコードに触れるなということになる
テストコードを書けと言われるけど • テストコードの品質ってどういうことだろう • テストコードが非常に長くなってしまう • テストコードを書いているのに品質上の問題が起きている
失敗例: 長い関数に対して無理やりテストを書く • 数百行程度の長い関数に対して後からユニットテストを書こうとしたが、大量のテス トケースが必要になってしまった。 • その関数が原因と見られる不具合が発生した。テストを増やして不具合の出るパ ターンを洗い出そうとしたが既存のユニットテストが何を保証していて何を保証して いないかわからず何週間もかかってしまった。
テストしやすい詳細設計 • 関数・メソッドは短い方がいい ◦ 行数が多くif文などを多く含む関数に対してテストをすると、分岐網羅や条件網羅を達成しようとす る際に難しくなる。 ◦ 場合にもよるが20行くらいに収めたい。 • 関数・メソッドは一つのことをする方が良い
◦ テストを書いたときテストの目的が分かりやすい。
アーキテクチャに問題があるケース
バックエンドに対してE2Eテストしか書けない • コントローラに殆どのロジックが書かれている • コントローラにか書かれているロジックをテストするために、DBに値を入れ、APIを 叩いてみるテスト(E2Eテスト)しか書けない • ユニットテスト保証すべき粒度の内容がE2Eテストに書かれていて、テストコードが 分かりづらい上実行が遅い •
サービス層等を導入しサービスに対してテストを書く等
何に責務を負っているか不明瞭 • 複数の責務を負っている関数は多機能になりがちで、テストが難しくなる場合が多 い。 • 責務が不明瞭なだけでも、テストケースが何を保証しようとしているか理解すること が困難になる。 • 単一責任の原則に基づいた設計をする
めちゃくちゃな依存関係 • 依存関係が乱雑になってしまっているシステムでは、大量の関数やモジュールを モックしなければならないモック地獄になる。 • DIを採用する、責務を見直すなどして依存関係を整理
シニアエンジニアとして • テストを書いてくれないことを嘆く前に、良い設計をして設計の意図をきちんと伝え る。 • レビューの際に初心を忘れず、テストなんて分かんないよという共通の前提に立っ てレビューする。
「強くてニューゲーム」しよう!