最近 TDD を開始し、開発する RESTful Web サービスごとに JUnit テスト ケースを作成しています。新しいバージョンがリリースされたときに、本番環境で JUnit テスト ケースを実行することは良い考えですか?
背景: 私たちの Web アプリはエンタープライズ Web アプリであり、複雑なビジネス ロジックがあります。@After と @AfterClass を使用して、テスト ケースの実行によって生成されたテスト データをクリーンアップする計画です。
Web アプリは、SaaS 版とオンプレミス版の両方で利用できます。実行可能であり、適切な方法である場合は、両方のエディションのアップグレードを検証する予定です。このテスト ケースをステージング環境で実行する予定であることは理解していますが、アップグレード/展開中に何も壊れていないこと、または環境がさまざまな影響を与えていないことを確認する必要があります。
ここでの質問は、「それは良い習慣ですか? いいえの場合、何が提案されていますか?」
単体テストはコードをテストするだけです。データベースや Web サービスなどの外部ソースで変更するべきではなく、統合テストになります。
一般に、プロジェクトをビルド/本番環境にデプロイする前に単体テストを実行することをお勧めします。これらは、ビルド サーバーまたは QA / ステージング サーバーで実行できます。すべて合格した場合にのみ、本番環境にデプロイします。ビルドがその意味で安定していることがわかります。
他のサービスと通信し、データなどを変更する可能性のある統合テストがある場合、私はこれらを本番環境で実行しません。本番環境にリリースされようとしているコードに対して、QA/ステージング サーバーでそれらを実行します。
これは興味深い質問です。完全な単体テスト スイートを実行したくないとは思いませんが、個別の展開スモーク テスト スイートの維持に投資したい場合があります。
理由 - テスト スイートが製品データベースに影響を与える可能性があります。たとえば、実際のテストのバグがロールバックに失敗するなどです。
また、本番環境でコードベース全体をテストするのではなく、問題なくデプロイされていることを確認するだけです (テスト スイート全体を実行したときに満足のいく結果が得られたと仮定します)。