テストピラミッドでもなくトロフィーでもなく、砂時計みたいな型が理想かも？
@hide_ramen_san: リリース前にはバックエンドの実装が完成してなかったりで、モックを使ったり、本来連携すべきデータを連携しないでテストしたりすることもあって、そういうのをE2Eテストじゃないというのはわかる。 ただリリース後の追加開発で、モック使ったりE2Eテストじゃないテストする理由あまり無い気がする。
@hide_ramen_san: 特には根拠も無いけどテストピラミッドの3階層じゃなくて単体テストとE2Eテストの2階層しかやってない場合そもそもあるんじゃないかなと。 一段目のユニットテストと三段目のE2Eテストを厚めにやって、二段目の結合テストはE2Eテストがやりにくい場合にのみやるので薄めになる。 @hide_ramen_san: ちょっと言い過ぎかもしれないことを言うなら、E2Eテストのコストが下がれば結合テストとか機能テストとか言われてるテストは中途半端でリグレッションテストとして繰り返しやる意味あまり無いんじゃないかな？と思ったりしてます。 一段目のユニットテストと三段目のE2Eテストを厚めにやって、二段目の結合テストはE2Eテストがやりにくい場合にのみやるので薄めになる。
@sumiren_t: E2Eのデメリットとして、カバレッジが得るためにケース数が乗数的に増えるというのもあると思うんですよね。理論上。 だから、ドメインやサービスの特性として複雑性が低く、機能の掛け合わせで発生する振る舞いのパターンが1 * 1 * 1 * ... = 1みたいになるなら、E2Eだけでも安心できるかも。
@YasuharuNishi: 今回感じたのはCI/CDのパイプラインどころかE2Eテストの自動化もかなり進んでること。日本ではTDDによるUTの自動化とかテストピラミッドが少し流行りすぎていて、本来進むべき技術進化の足枷になりつつある気がする。大丈夫かしら。 @hide_ramen_san: 西さんの意図とは違うかもしれないですが、テストピラミッドが理想という主張がE2Eテストのコストが理由だとしたら、技術進化によりE2Eテストのコストが下がれば理想形も変わるんじゃない？とは私も何回かツイートしてる。 @hide_ramen_san: E2Eテストのコストが高いっていうのは、実行速度が遅いからだったら並列で実行すれば解決するから速度が問題ではない気がするんですよね。 おそらく管理コストというか、一箇所の変更が複数テストケースに影響するからだと思います。 @hide_ramen_san: たとえばECサイトで会員登録してから検索するテストケースと会員登録してからいいねを付けるテストケースがあるとして、会員登録のUI変更で両方のテストケースが動かなくなるかもしれないですよね。 ただ、それはAIで一括置換できたりして解決するようになったら良いなと思ってるということです。 AIを活用してE2Eテストのコストを下げる