skillup

技術ブログ

プログラミング全般 プロジェクト管理

テストコードの書き方の注意点

投稿日:2023年6月25日 更新日:

テストコードを実装する様になって1年ぐらいたったのですが、そこできづいたことなどを。

タイトルをわかりやすく

後述しますが、仕様書としての目的があるため、関数名をなるべくわかりやすくすることがポイントかなと思います。この辺りは日本語で書いてもいいかもしれません・・・

正常系1、異常系1・・・などだと意味不明なので、なるべくなにをテストしているのかがはっきりわかるようなテストが望ましいです。

値をなるべく具体的に書く

configやenvの値などを関数で値をもってくるのではなく、直の値で直接かくようにしましょう。

  • 設定が変わったことにきづかない
  • 後述するテストコード=仕様書の役目がおちてしまう

疑似的な仕組みはなるべく避ける(例:Mock)

APIや外部環境などとの結合ではMockをつかったりすることもありますが、どうしてもMockを使わないと行けない場合(APIの制限がある、開発途中で呼び出せない)以外は、なるべく本環境に近い環境でテストをするのがよいです。

Mockをつかっていると依存度が下がる・・・などのメリットもありますが、呼び出し側が変わったか、つなぎ目の検証ができないためです。

ユニットテストの流派

仕様書として機能させる

テストコードの品質としてカバレッジが一通りの目安にはなりますが、最終的には仕様書のように機能するのがベストだと思っています。

そのため、単に動作正常性を担保するのではなく、ビジネスロジックをしっかりと担保しているか(前提データなどがそれに則っているか)を注視しましょう。

粒度の統一

例えばAPIのテストをする場合でも、大まかにざっくりわけると

  • 全体を通したテスト
  • バリデーションのみのテスト
  • モジュール間のテスト(ServiceなどAPIの一部で使われているものもそうですが、Modelなどの単体テストなども。)

など部分ごとに分けられると思います。カバレッジをつかって見た目100%にしても粒度が整っていないと仕様書としての機能が弱くなるため、粒度の統一は必要になってくるでしょう。

テスト同士の依存をうまないようにする

あるテストコードからあるテストコードを呼び出さないようにしましょう。

よくあるケースとしては初期データ投入などですね。

この場合、traitなどで独立したクラスを作るか、factoryパターンなどでデータを簡単に作れる仕組みづくり、またマスタ系に関してはseederとして独立させるのがよいです。

時間軸をずらす際の注意

時間がたったことを確認したり、測定したりするテストが結構あるかとおもうのですが、不用意に埋め込むとテストのたびに成功と失敗が入り混じるようなflakyテストになります。

時間を経過させる場合、sleepを使ったりすることが多いかと思いますが、不用意にこれを使うのではなく、時間を固定するような関数(LaravelでいうとところのsetTestNow)を使うようにしましょう。

FlakyTestとの戦い

CarbonのSetTestNowの仕様変更

異常系に関しては棲み分けを

異常系のテストですが、できるものできないものをわけましょう。

できない(テストしなくて良い)ものに関しては、完全な500エラータイプでDBが落ちているとかそういったケースでないと試せないタイプです。

そういったケースは起こり得ないのでMockを使ったりしない限りは起こすことが難しいため、テスト不要かと思います(DBを落として無理やり実行するなどもありえますが・・・)。

逆に500以外の起こり得るエラー(NotFoundException、ValidExceptionなど)はしっかりとテストするようにしたほうがよいでしょう。

-プログラミング全般, プロジェクト管理
-,

執筆者:


comment

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

関連記事

no image

プロジェクトマネジメントについて

ある程度、大規模なプロジェクトを経験させていただき、経験だけでなくプロジェクトマネジメントを体系的に理解しておきたいため、ポツポツと本を読んでます。 比較的初心者でも読みやすいと思った本としてを2冊メ …

no image

エンジニアの評価指標の策定について

営業の方であれば、月間の売上以外に新規の見込み数や、見込み客でも確度別の分類数など様々な指標で評価されることが一般的だと思います。 これらは「結果」に対する指標なのですが、それ以外でも見込み客に対する …

no image

コメントについて

リーダブルコード 第5・6章はコメントについて。 今回はコメントです。ここは結構賛否両論になるところではないかと思います。 ざっくり分けると「できるだけコメントは詳しく書くこと」という意見と「コメント …

no image

読書感想文:ITエンジニア採用とマネジメントの全て

前回に引き続き採用の本の読書感想文を 今回読んだ本は「ITエンジニア採用とマネジメントの全て(久松剛)」です。 著者の方は某大手企業で有名なエンジニアリングマネージャーを務めている方でここ10年ぐらい …

no image

チーム内の行動変容(定着する、しない仕組みづくりについて)

学習塾時代からそうだったのですが、チーム内で新しいとりくみなどを始めてもなかなか定着せずに忘れ去られてしまう仕組みものというのがいろいろありました。 以下で書きましたね・・ 文化づくりについて(チーム …

アーカイブ