2023/8/11のメモが寝ていたのでブログに書いておきます。

UIテストを自動化しよう！と思ったとき・・・

パターンは２つ。 ひとつは、今ある手動テストケースをそのまま自動化しよう！というパターン。 これはあんまり悩まずに自動化できることが多いです。（それが良いこととは言い切れない）

もうひとつは、自動化する前提でテスト設計（＆その前段階）からやるパターン。

今回の話は後者。

たとえばよくありがちな、Webサイトのログイン処理のテストを自動化しよう、と考えたとします。 ここではいくつかの考え方があります。

  • IDとパスワードのフォームでそれぞれ正常系異常系のテストをする
    • 文字数超過、使用できない文字種を入れる、空欄、IDとパスワードの誤ったペア、などなど・・・
  • IDとパスワードの文字数や文字種は正常系のみで、正しいペアでログインできることと、誤ったペアでログインできないことの2通りをテストする

最初に示した1つ目のパターン、すなわち元々手動でやっていたテストケースがあってそれを自動化する場合、前者の作りになりがちです。

一方、自動化前提でテスト設計をしていく場合、自分はE2Eテストは後者にしたい派です。

すると、前者に比べて見ている範囲が狭いので、不安に思う人が出てきます。あるいは、開発者からすると「えっ、QAなのにテストを簡素にやるの？ケース増やしてたくさんやりたいんじゃないの？」と思われたりする。かもしれません。

ここがけっこう大事なポイントだと思っていて、E2Eテストでテストケースを絞ったときに、そこから漏れたものはつい「テストしない」ように感じられてしまいます。

実際にはそうではなくて、「E2Eテストではやらない。他のテストレベルでどうカバーしようか？」という話になるのが正しいはずです。単体テストでやろう、なのか、結合テストでやろう、なのか。 そうなると、、E2Eテストをどんな粒度で行うか、つまり細かいバリデーションまで見るのか、もう少し正常系と異常系の基本パターンに絞って行うのか、を決めるためにE2Eテスト以外のところを考えなければいけないですね。

テストの全体像から考える

この先は「自分はこんなふうにやってみてます」という話で、絶対の正解ではないと思う。ので、ツッコミをむしろください。

テストの全体像、今回は自分が表現しやすかったからという理由でテストコンテナを使っていて、その中でE2Eテスト自動化でやりたいのはココ、という順番で考えるのが良いと思ってます。