ATDD(受け入れテスト駆動開発)から、増え続けるテストの難しさを考える

プロダクトの成長という視点を引き合いに出しつつ、成長とともに増えるE2Eテストの在り方を考えてみます。

ATDDを実践している観点から書いてみます。

まず、ATDDとは

ATDD(受け入れテスト駆動開発)というもの

これは

• はじめに、受け入れテストを書き
• そのテストがパスするように実装をする
  というものである。

今いる会社のATDDのやり方

今いる会社の場合

• テストシナリオを書いて
• Seleniumの Webドライバーで動くテストによってエンドツーエンドのテスト実装する
• そのテスト実装をパスさせ
• パスした後にリリースを行う

つまり、機能開発の度に受け入れテスト、テストシナリオを書くのである。

ATDDのメリット

これらのメリットは

• シナリオという明文化された機能に対しての文書が毎回生まれること
• プロダクトマネージャーやプロダクトオーナーにとっても分かりやすい文章。チームのプログラマにしか読めないようなものではない文章が作られること
• テストを前提として実装していくテストファーストであること
  などが挙げられる

ATDDと言っても色々あるのだろうが、今いる会社ではそのようにやっている

ATDDの難しさ

これは小さなプロジェクトのうちは良いのだが
プロダクトが成熟していき、サービス自体も大きくなっていくと段々と問題が発生する。

まず、E2Eテストとはエクスペンシブなものであること。コストが高い
TDDの観点だと、レッド・グリーン・リファクタリングのサイクルが遅くなりやすい。
ユニットテストなどでテストケースを書き→実装を書き→テストを実行し→…というサイクルを回すのと比較して、ゆったりとしたフィードバックループになってしまう。
なので、これはなかなか TDDというやつの旨みを活かしにくいであるのではないかと思う。

ユニットテストが隠れてしまう

はじめにブラウザで動作するテストを書くため、ユニットテストなどをする必要性が薄れてしまい、ユニットテストを書くという行為が減ってしまう。という罠がある。
言い換えると、ユニットテストやインテグレーションテストがSeleniumによるエンドツーエンドのテストによってまかなえてしまうということである。

プロダクトが成熟するほど、テスト実行が長くなる

これはATDDに限った話ではないが
機能が増えれば増えるほど、E2Eテストの全体時間は長くなり重くなり不安定になる。
それらをメンテし、壊れやすいテストを保証し続ける必要がある

これらの問題をどうするか

ATDDでプロダクトを育てていくと、前述したような問題に直面することがあるのかなと考えている

サービスが順調に進めば進むほどプロダクトが成長すればするほど。この問題は深刻化していく

では、どうすれば良いのだろうか？

テストピラミッドを維持する

ヒントとなるのはテストピラミッド、テストトロフィーのようなものと考える。

簡単に言ってしまうとテストピラミッドを維持するため

• 不要になったE2Eのテストを捨てる。元から不要なものは書かない
• エンドツーエンドのテストではなく、ユニットテストなどで代替できるところは変更していく。もしくは元からユニットテストを書く
• 細かく分けすぎた機能のシナリオを集約していくことでテストケースを減らす
• コードベースを分けてテストケースや実装を小さく留める

などの対策を打つ。

こういったアプローチを取ればテスト実行時間が長くなることは避けられ、効果的な検証をし続けることができる。
CI なども遅くなることはなくなり、フィードバックサイクルを回すことを維持できるはず。

コードベースの分け方

コードベースを分ける方法としては、マイクロサービスやマイクロフロントエンドなどが考えられる。

ただし、テストを早く保つためだけにサービスを開けるというのは本末転倒であり、注意が必要な点である。
ビジネス、業務ドメインの単位でテストスコープを区切り、サービスを区切るということが重要な気がする。

CIやデプロイメントパイプラインなどで工夫する

サービス規模にもよるが、全テスト実行が遅くなっていくことを許容し、CIの実行回数や実行タイミングを限定的にすることで対処することも考えられる。

まとめ

色々書いたのだけど、補足すると
ATDDは、なんだかんだ全てに対してテストが書かれているっていう安心感はすごい。

何かリファクタリングをして動かなくなった機能があれば、ちゃんとテストが失敗してくれる。

一方で、プロダクトの成長とともに複雑さも増していく。そこの課題感や解決法も考えてみたかったので、今回ブログを書いてみた。

実は、こういった悩み、課題感が深刻になるのはプロダクトやサービスがかなり大きくなった段階になってからである可能性は高い。

小さい規模や、小規模から大きくなり始めたぐらいであれば、この記事で書いたような創意工夫で騙し騙しなんとかやってくるのではないだろうか。

かなりの大規模なサービスで、こういったテストを大量に抱えている場合は

腰を据えて、様々な部分で戦略的アプローチが必要な気がする。

しかし、共通しているのは

• 不要なものは捨てること
• 不要なものは書かないこと
• 細かすぎるものを集約すること
• 適切な手段を選ぶこと

かもしれない。

まあ大体ここに書いてあるんですけどね

https://gihyo.jp/dev/serial/01/savanna-letter/0005