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

クラスメソッドとインスタンスメソッド

以前staticメソッドを定義したときに、記法がインスタンスメソッドの呼び方でも呼べてしまうことがあったので、これを機にインスタンス・クラス×変数・メソッドちょっと調べてみました。 言葉で書くよりコー …

no image

シェルの基礎+ユーザー切り替え関連

雑誌を見ていたらシェルの特集があったので、ちょっとメモリます。 補強したいところのみ要点をチェック。 Contents0.1 実行パスについて0.2 ビルドインコマンド0.3 シェル変数・環境変数0. …

no image

採用面接の質問、判定基準について

採用ネタについて色々と書いていますが、自分の社会人生活で人の横で採用を見ていてあまり良くないな・・と思った質問の類と聞いた方が良いと思う質問(採用基準)に対して。 Contents1 NG系の質問1. …

no image

短いコードを書く

私が普段コードを書くときに考えていることは常にいかに短くかけるか、ということといかにバグを生み出さないかということです。 基本的にはできるだけ、短くシンプルに書くようにしています。 そうすることであと …

no image

CIことはじめ

業務でJavaのテキスト変換ツールを作成。 プログラムよりもCIツールを使って他人の環境下で正常に稼動させるためにどうするかの調査に時間かかりましたね。 今回やりたかったことは下記の通りです。いわゆる …

アーカイブ