私はこの状況全体に本当に不満を感じています。その理由は次のとおりです。
多くの異なるクライアントデータベースと1つのマスターデータベース（異なるスキーマを持つ）の同期を維持するために、完全にテストされていないレガシーシステムを継承しました。システムは私に渡されたときに部分的にしか完成しておらず、多くの欠陥があり、90％の確率で正しく機能していませんでした。
このシステムでは、6種類の同期が許可されており、データベースはかなり大きくなる可能性があるため、それぞれが異なる（場合によっては重複する）テーブルを同期します。クライアントは、状態に応じて最も重要なテーブルに優先順位を付けることができます。
いくつかのエンドツーエンドのテストから始め、特定のデータを使用してマスターデータベースといくつかのクライアントデータベースをローカルにセットアップし、さまざまな同期メソッドを呼び出して、適切なデータが適切な形式で適切なデータベースに表示されることを確認しました。
私は時間に追われていました。このシステムには、データベース間でデータを移動する方法が少なくとも100通りあり、コードは数千行しかないため、エンドツーエンドのテストをどんどん行っていきました。基本的に、プロジェクトを引き継いだときに存在した欠陥ごとに1〜2個。私は16の単体テスト（追加したコードからTDDを実行）と113のエンドツーエンドテストでシステムを完成させました。これらのテストの多くは、以前の欠陥に直接基づいていました。
私はシステムを完成させました、そしてそれは何事もなく数ヶ月間生産されました。
最近、クライアントデータベースを新しいデータベースに変換することを決定しました。新しいデータベースでテスト（この間ずっとCIサーバーで毎晩実行されていました）を実行すると、113のうち約100が失敗しました。（もちろん、ユニットテストはすべて合格です）。
私は失敗したエンドツーエンドのテストを修正してきましたが、率直に言って、ほとんどの場合、1つまたは2つの単純な理由で失敗しました（新しいデータベースの丸めの日付が異なるなど）が、テストが非常に脆弱であるという事実に不満を感じています。それらは正しく失敗しましたが、100ではなく1つか2つしか必要ありませんでした。問題は、ほとんどの場合、日付に基づいて1つのテーブルからデータを選択するだけなので、単体テストするコードがそれほど多くないことです。別のデータベースから同じデータを選択し、2つをマージしてから、適切に挿入/更新します。
これらのテストなしでこのシステムを完成させる方法はありませんが、それらを維持することの苦痛は基本的に私をこの質問に導くものです：私がどのように進めるべきか/または私がより良くできたかもしれない何か提案？これらのエンドツーエンドのテストを初めて作成するのに多くの時間を浪費しましたか？「レガシーコードを効果的に使用する」を読みましたが、「リファクタリングしてより多くの単体テストを作成する」以外は、私が感じていた種類の痛みについては、あまり良い答えがないように感じました。このシステムのユニークな性質に対して、コードが非常に少なく、データベースの変換が多いというオプションがあります。