書きました！
読み応えありすぎだろ。これ無料で公開していいレベルの質と量じゃないか
とてもよくまとまっている "実行時間の物理的な遅延、ネットワーク越しの確率的失敗、組み合わせ爆発という数理的性質はテストコードの作成者が人間からAIに代わっても解消されません"
またAIに書かせた冗長な記事かいなと思って読み始めたが、大変参考になった。マージ前のCIが必須化されているプロダクトのE2Eがやたら長く、待つのが仕事みたいになっている時があるので、その時にじっくり読もう。
追加するとしたらE2Eテストしやすい裏APIの作成かな…CRUDのRだけあれば良い、APIならGetがあれば良いPostPut要らないよと言われても作っておくとテストがしやすくなる。テストしやすい設計を理解してくれる人は少ない。
E2EテストをAIに書かせても、実行の待ち時間や組み合わせ爆発は消えない。決済の分岐は単体テストで確かめ、E2Eには主要経路の貫通確認を残す。生成の速さと、検証を回し続ける費用を分けて設計したい。
で、これをAI君に読ませたらいいのかな
E2Eテスト大全（あなたの知らない、E2Eテスト周辺の理論） - 若くない何かの悩み
書きました！
読み応えありすぎだろ。これ無料で公開していいレベルの質と量じゃないか
とてもよくまとまっている "実行時間の物理的な遅延、ネットワーク越しの確率的失敗、組み合わせ爆発という数理的性質はテストコードの作成者が人間からAIに代わっても解消されません"
またAIに書かせた冗長な記事かいなと思って読み始めたが、大変参考になった。マージ前のCIが必須化されているプロダクトのE2Eがやたら長く、待つのが仕事みたいになっている時があるので、その時にじっくり読もう。
追加するとしたらE2Eテストしやすい裏APIの作成かな…CRUDのRだけあれば良い、APIならGetがあれば良いPostPut要らないよと言われても作っておくとテストがしやすくなる。テストしやすい設計を理解してくれる人は少ない。
E2EテストをAIに書かせても、実行の待ち時間や組み合わせ爆発は消えない。決済の分岐は単体テストで確かめ、E2Eには主要経路の貫通確認を残す。生成の速さと、検証を回し続ける費用を分けて設計したい。
で、これをAI君に読ませたらいいのかな