テストが壊れ続けるのはなぜですか？なぜそれらはバグが多く、保守できないのですか? それがあなたの問題の根源です。
テストは、ソフトウェアの要件を表す必要があります。それらが壊れ続ける場合は、パブリック インターフェイスを介してコードを呼び出すだけでなく、実装の内部と密接に結合されていることが原因である可能性があります。パブリック インターフェイスを介してコードを駆動できない場合は、通常、コードをよりテストしやすいように設計する必要があることを示しています。これにより、コードがより明確で、より柔軟で、堅牢になる傾向があります。
テストを削除すると、コードベースがまだ機能するかどうかわからなくなります。「バグがある」という理由でテストを削除すると、厄介な質問が残ります。テストにバグがある場合、実際のコードのバグが少ないのはなぜですか?
一方、（レガシー）テストがひどく遅くて厄介な場合、少なくともそれらのいくつかは価値があるよりも面倒かもしれませんが、ケースバイケースでそれらを考慮する必要があります.それらをどのように置き換えるかを考えてください。テストの時間を計って、対象となる特に遅いテストがあるかどうかを確認できます。それらが JUnit テストの場合は、タイミングを自動的に取得します。また、コード カバレッジを測定して、テストが重複しているかどうか、またはサイズと実行時間を考慮して非常に少量のコードベースをカバーしているかどうかを確認することもできます。レガシー コードを扱うトピックに特化した書籍がいくつかあります。
自動化されたテストが適切に行われると、開発が遅くなるのではなく、スピードアップします (ソフトウェアを実際に動作させたいと仮定した場合)。 「機能しているように見える」とは対照的に、機能がいつ機能しているかを明確に知ることができます。
テストのスピードアップが望ましいでしょう。システムをエンドツーエンドで実行している場合、すべてのテストが高速になるわけではありませんが、私は通常、そのような「機能テスト」を、常に実行できるように非常に高速に実行する必要があるきめ細かい単体テストとは別にしています。単体テストの定義と遅いテストの扱い方については、Michael Feathers によるこの投稿を参照してください。
コードが機能するかどうかに関心がある場合、テスト コードは実際のコードと同じくらい重要です。重複を避けるために、正確で明確で、因数分解されている必要があります。比率はコードの種類によって大きく異なりますが、少なくとも実際のコードと同じくらい多くのテスト コードを使用することは完全に正常です。あなたの特定の例が過度であったかどうかは、それを見ずして言うことは不可能です。
更新:他の質問の1 つで、「最新の気の利いたフレームワーク、単体テストと機能テスト、CI、バグ トラッカー、アジャイル ワークフローを環境に導入しました」と答えています。テストについて考えが変わったのですか、それともこの質問は、おそらくストローマンですか? それとも、あなたの質問は本当に「古いテストをすべて破棄して、最初からやり直すべきですか」ですか? (開発者が新しいテストを書いているというあなたのコメントを考えると、そのようには読めません...)