テーマ、知りたいこと
フロントエンド、バックエンド、DBの構成でシステムを提供しているとして、
どれくらいの自動テスト（ユニットテスト、インテグレーションテスト、E2Eテスト、etc）を書いていますか？どの層（UT/IT/E2E）を手厚く書いているか、特にITってどれくらい書くものなんだろうというのが気になっています。あと、意外と大きめの改修をするときE2Eあるとありがたいなと思うのですが、あんまりたくさん書かないものなのでしょうか？
背景、状況
今でこそAIで書きやすくなっていると思いますが、
テストコード書くのも大変ですし、保守コストもかかりますし、実行時間も長くなり開発速度に少なからず影響が出ると思います。
デグレなど怖いのでテストピラミッドの考え方で、かつDDDでやっていたりするのでビジネスロジックなどコアな部分を中心に整備するようにしていますが、みなさんのプロジェクトでどうしているか、伺いたいです
回答1件
#1
総合スコア20
投稿2026/06/24 13:15
個人的な現場感としては、基本はテストピラミッドの考え方で、UTを一番厚く、ITは重要な境界部分、E2Eは主要導線に絞ることが多いです。
DDD寄りの構成であれば、ドメインモデルやユースケース層など、ビジネスルールが集中する部分はUTでかなり手厚く書きます。仕様変更時に一番壊れてほしくない部分なので、ここはコストをかける価値が高いと思います。
ITについては、全パターンを網羅するというより、DB・ORM・トランザクション・Repository・外部API連携など、「モックでは不安が残る部分」を中心に書くことが多いです。特に複雑なSQL、集計処理、権限制御、ステータス遷移、排他制御、マイグレーション影響がある箇所はITがあるとかなり安心できます。
E2Eは便利ですが、実行時間や保守コスト、テストの不安定さが出やすいので、あまり大量には書かない印象です。ログイン、登録、購入、申請、承認、決済など、サービスの主要シナリオや売上・業務上止まると困る導線に絞って、スモークテスト的に置くことが多いと思います。
大きめの改修時にE2Eがありがたいのは本当にその通りで、全部をE2Eで守るというより、「最低限ここが通れば致命的なデグレではない」と判断できる導線を持っておく、という使い方が現実的かなと思います。
なので、自分なら目安としては、ビジネスロジックはUT中心、DBや外部境界はITで代表ケースを厚めに、E2Eは重要導線だけ少数精鋭、というバランスにします。AIでテストは書きやすくなりましたが、結局メンテナンスするのはチームなので、量よりも「何を壊したくないか」から逆算するのが大事だと思っています。
あなたの回答
tips
プレビュー