テストに慣れてないと テスタブルなコードって 書けないよねという話 テスト失敗談

しぐま Sigma ● 株式会社エヌエルプラスに去年入社しました。 ○ リファラル採用やってます！ ● イベント配信プラットフォームやってます。 ● 現在は主にNuxtとGoとGCPを触っています。 ● 一応シニアエンジニアです。

テストが益々重要になってきた ● 品質が保証されていないとあらゆるコードの修正に待ったが入る ○ ビジネスサイドとしては、利益に繋がらない目的で動いているコードを変えるということに抵抗があ る。それが許されるのは十分に品質が保証されている場合だけ。 ● アジリティを保つには自動テストが必要 ○ 素早く変更し、素早く既存部分を含めた全ての機能が動いていることを保証し、実装した機能素早く リリースするためには自動テスト以外の方法がない。 ○ 幸い道具は全て持っている。 ● 最悪の場合動いているコードに触れるなということになる

テストコードを書けと言われるけど ● テストコードの品質ってどういうことだろう ● テストコードが非常に長くなってしまう ● テストコードを書いているのに品質上の問題が起きている

失敗例: 長い関数に対して無理やりテストを書く ● 数百行程度の長い関数に対して後からユニットテストを書こうとしたが、大量のテス トケースが必要になってしまった。 ● その関数が原因と見られる不具合が発生した。テストを増やして不具合の出るパ ターンを洗い出そうとしたが既存のユニットテストが何を保証していて何を保証して いないかわからず何週間もかかってしまった。

テストしやすい詳細設計 ● 関数・メソッドは短い方がいい ○ 行数が多くif文などを多く含む関数に対してテストをすると、分岐網羅や条件網羅を達成しようとす る際に難しくなる。 ○ 場合にもよるが20行くらいに収めたい。 ● 関数・メソッドは一つのことをする方が良い ○ テストを書いたときテストの目的が分かりやすい。

アーキテクチャに問題があるケース

バックエンドに対してE2Eテストしか書けない ● コントローラに殆どのロジックが書かれている ● コントローラにか書かれているロジックをテストするために、DBに値を入れ、APIを 叩いてみるテスト（E2Eテスト）しか書けない ● ユニットテスト保証すべき粒度の内容がE2Eテストに書かれていて、テストコードが 分かりづらい上実行が遅い ● サービス層等を導入しサービスに対してテストを書く等

何に責務を負っているか不明瞭 ● 複数の責務を負っている関数は多機能になりがちで、テストが難しくなる場合が多 い。 ● 責務が不明瞭なだけでも、テストケースが何を保証しようとしているか理解すること が困難になる。 ● 単一責任の原則に基づいた設計をする

めちゃくちゃな依存関係 ● 依存関係が乱雑になってしまっているシステムでは、大量の関数やモジュールを モックしなければならないモック地獄になる。 ● DIを採用する、責務を見直すなどして依存関係を整理

シニアエンジニアとして ● テストを書いてくれないことを嘆く前に、良い設計をして設計の意図をきちんと伝え る。 ● レビューの際に初心を忘れず、テストなんて分かんないよという共通の前提に立っ てレビューする。

「強くてニューゲーム」しよう！