1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

初心者が感じたテスト自動化あるある

Posted at

今年の4月にHITOTSUに入社し、Playwrightを使用したテスト自動化の実現に向けて日々取り組んできました。前職ではRPA開発に携わっていたものの、業務でコードを書く機会はほとんどなかったため、新しい分野に挑む期待と不安を抱えながらスタートしました。今回は、この9ヶ月間の経験を通じて感じた「初心者にありがちだな」と思うことについて書いてみたいと思います。

テストコードを書くことに集中しがち

初心者にありがちなのが、テストコードを書くことにばかり集中してしまうことです。もちろん、テストコードを書くことは重要ですが、それだけではテスト自動化を実現することはできません。実際にテスト自動化を進めるためには、まずテストが動く環境を整えることが必要です。CI環境で何かを実行してみることを優先することで、テストコードが完成した際にスムーズにCI環境で動かせるようになります。

様々なテストを一度にやろうとする

できるだけ多くのテストを一気に実行したいという気持ちから、たくさんのコードを書き進めていました。しかし、中には難しい部分もあり、なかなか完成に至らず悩んでいました。そこで、最初の目標を「簡単な操作のテストを毎日回すこと」に設定し、一度に多くのことをやろうとするのを控えることに決めました。実際、毎日回してみると、簡単な操作のテストでも失敗することが多々ありました。失敗の原因はさまざまですが、大抵は要素の出現を待機するなどの工夫で、失敗を減らすことができました。もし最初に多くのテストを一度に作成して実行していたら、一気に多くの失敗が発生し、対応が大変になっていたかと思います・・。

自動テストは多ければ多いほど良いという考え

はじめは、できるだけ多くのテストを自動化した方が良いと考えていました。しかし、テストについて学んでいくうちに「テストピラミッド」という概念を知りました。テストピラミッドとは、テストの種類を階層的に分けたもので、理想的にはE2Eテストが一番少なく、下層に位置するユニットテストやサービスレイヤーのテストが多くなる構造です。

なぜテストピラミッドが有効かというと、E2Eテストは実行に時間がかかり、壊れやすいため、継続的にメンテナンスするのが難しいという点があります。一方で、ユニットテストは個別の機能を高速にテストでき、変更にも素早く対応できます。ユニットテストを多く実施することで、システム全体の動作を確認する前に個別のバグを早期に発見でき、効率的に品質を保つことができます。したがって、「自動テストは多ければ多いほど良い」という考えは正しくないということです。

最後に

まだまだ分からないことや、どうすべきか悩んだりすることもあり、学ぶべきことは多いですが、これからも試行錯誤しながら、より効率的で安定したテスト自動化を実現していきたいと思います。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?