はじめに
テスト自動化あるある言いたい by T-DASH Advent Calendar 2024の24日目の記事です。
テスト自動化にあたって、既存の手動テストをもとに、E2EフレームワークやXUnitなどでテストコードをつくっていくのが主な流れです。それ自体はいいのですが、手動テストの手順をそのままテストコードに落とし込むと問題になるケースがあるので、それのまとめです
忙しい人向けのまとめ
- 手動テストの手順をそのままテストコードに落とし込むと、手動のときの問題点が引き継がれる、場合によってはその問題が強化される
- 手動では時間的な制約でできなかったことを、テストコードにする際、見落としてしまう
- 前提が手動から自動に変わるので、最適解が変わることを意識する必要がある
パターンの網羅性周り
前提が手動から自動に変わる際、パターンの網羅性を見直した方がいいです。
- 手動前提だと、時間の都合上、一部のパターンしかできていなかった
- 手動でも、がんばって全パターンを網羅していた
このどちらの場合でも、
- パターンが網羅しつくされているかどうか
- 網羅性のテストに必要な範囲をなるべく小さくできないか
の観点で見直すとよいです。
parameterized testを使う
自動テストのメリットのひとつは、数をたくさんこなせることです。なので、パターンは可能な限り網羅しつくしたいです。手動のときは数をこなそうとすると、制約が多すぎて現実的でないことがままあります。
JUnitであれば、ファイル、コードなどの様々な形で入力ソースを定義できるので、それらで全パターンを定義できます。ラジオボタンやセレクトボックスの値をEnumで管理するケースが多く、EnumSourceを使えば簡単にパターンを網羅したテストを作成できます。
また、assumptionの機能もつかえば、細かな分岐も対応しやすいです。
https://junit.org/junit5/docs/current/user-guide/#writing-tests-assumptions
テスト対象のコードを見直す
一方で、網羅性の担保だけを考えていると、テストの実行時間がどんどん増えてしまいます。一回の実行時間が伸びれば伸びるほど、繰り返し実行されづらくなり、開発の足を引っ張るなどの問題がでます。
「速く、たくさんの数をこなす」ことが自動テストのメリットです。テストコードの実行時間を短くするには、テストで使われるコードの範囲を必要最低限にすることです。
手動テストで全パターンを網羅していたとしても、
- 特定のクラスのテストコードに帰着できないか
- controller + view or repository + controllerなど、使用するレイヤーを減らせないか
テスト対象のコードを減らす（小さくする）ことを検討するとよいです。
自動テスト用の専用の環境を用意する
E2Eテストフレームワークを試すために、既存のstagingや開発環境をそのまま使うことがままあると思います。
手動テストで運用している場合、そういった形をとることも多いのでE2Eテストもそこからはじめようとするのも、よくあるケースでしょう。
本当に試すだけであれば問題ありませんが、その状態で自動テストを増やそうとするとまずうまくいきません。自動テスト用のためのデータが変更されないことを担保できないため、自動テストの結果が安定しません。
数がすくないうちは、自動テスト用のデータをチームに周知などの運用で回避できますが、増えれば増えるほど、そんな運用では機能しなくなってきます。自動テストを安定させるためには冪等性（同じ入力すれば、毎回同じ結果になる）の担保が重要です。そのためには専用の環境を用意し、テストデータもテストの実行前後でいれかえるなどして、同じ状態でテストできるようにしましょう。