Guidelines for GUI testing maintenance: a linter for test smell detection | Proceedings of the 13th International Workshop on Automating Test Case Design, Selection and Evaluation中で挙げられている「GUIテストメンテナンスのためのガイドライン」の項目を、論文中でその根拠とされている情報源を見ながらコメントする記事です。
項目と訳
Keep the number of unit tests greater than the numberof end-to-end tests
E2Eのテストの数よりも、ユニットテストの数のほうが多い状態を保とう
読み解き＆感想
uselagoon/lagoon: Lagoon, the developer-focused application delivery platform のリポジトリにて、「プロジェクトのコード品質上げるために議論しようぜ」的なDiscussionsが作成されていて、そこへのコメントで
- テストスイートの改善が最優先だと思う。
- 現状アイスクリームコーンになってる。
- ユニットテストを考慮したリアーキテクチャが要る。いまのままだと難しい。 といった趣旨の発言をしている人がいました。
もうひとつの情報源であるmrchecker/mrchecker-modules-examples/mrchecker-docs/documentation/Who-Is-MrChecker/Test-Framework-Modules/Selenium-Test-Module-Selenium-Best-Practices.asciidoc at main · devonfw/mrcheckerでは、内容が変わったのか正直近い言及がないようにみえます。
前者はテストピラミッド・アイスクリームコーンを引き合いに出してコメントしているのでこういったガイドライン項目として抽出されたのだと思います。が、個人的には賛成しきれない、です。
テストピラミッドでは確かに「遅くて高コストなGUIテストよりも、ユニットでできることはユニットで」と言われていますし、ユニットを厚めのほうがいいと言われています。しかし、直接テストケース数には言及していないようにも思います。
ズルいことを言えば、GUIテストのシナリオを長大にしたり、逆にユニットテストをかさ増しすればハック可能ですし。もちろんこのガイドラインで言っている数の大小は「無駄なこと・余計なことをしないで」という前提が暗黙のうちにあるのでしょうけれど。
Selenium Conf Tokyo（2019年に開催）で、単純にテストの数がピラミッド型になればいいわけではない、という発表を聞きました。
テストケースの数を見ると、ピラミッドになってる。
でも実行にかかる時間は・・・
スライドは以下とほぼ同じのはずなので、見たい方はこちらでも。 Test Impact Analysis. Smarten up your pipeline and reduce test time. – DelEx Conference: DevOps & Test Automation
発表自体は、このあと改修などの影響がある箇所を分析することでそもそものテストを減らして実行時間を削減する、という流れだったと思います。
これ聞いて「たしかにそうだわ」と思った記憶があるので、テストケースの数だけに着目するのはちょっと足りないかも、とこのガイドライン項目を見て感じました。
ただ、ケース数がユニット＜E2Eになってたらたしかにそもそもダメでしょ、と言われればそうなので、最低限数はユニットのほうが多くあれよ、という主張に関しては間違ってはいないのかもしれません。
補足
論文中ではFile not foundを引用していましたが、2024/4/13現在アクセスできない状態です。 おそらく移動していて、こちらのことだと思われます。mrchecker/mrchecker-modules-examples/mrchecker-docs/documentation/Who-Is-MrChecker/Test-Framework-Modules/Selenium-Test-Module-Selenium-Best-Practices.asciidoc at main · devonfw/mrchecker