私は、並行開発環境で絶えず強化されているWebアプリケーションに取り組んでいます（2つの異なる環境で2つの要件を開発し、最初の要件が本番環境にリリースされたときに、最初のコードベースを2番目にマージします）。
私の質問は、アプリとそのメンテナンスのテストと単体テストの両方を統合することについてです。
モッキングを使用した単体テストでは、並行開発でテストを維持することが難しくなり、並行開発での統合テスト (セレンを使用) では、データベースに必要なデータを維持することが難しくなります (失敗した単体テストを修正するよりも簡単かもしれません)。
コードをマージしてもユースケースが壊れることはないため、統合テストに傾倒していますが、期待のためにコードをマージすることでユニットテストケースが失敗する可能性があります。アプリは少し古く、適切に設計されていません。単体テストとコードのリファクタリング、および単体テスト ケースの維持が難しくなっています。テストのためのより良いアプローチを提案してください。
単体テストと統合テストはどちらもその役割を果たします。ユニットテストは、その名前が示すように、ユニットが期待どおりに動作していることを確認します。統合テストが単体テストでカバーされているのと同じコードをカバーしているのは事実です。ただし、単体テストは、問題をより簡単に特定するのに役立ちます。システムのどの部分が問題の原因であるかを理解するための失敗を調査する代わりに、あなたはあなたが見つけるのを助けるために失敗したユニットテストを持っています。ユニットテストを行うもう1つの理由は、速度です。ユニットテストは高速である必要があります。さまざまなシステム依存関係に依存するべきではありません（そのためにモックとスタブを使用する必要があります）。カバレッジの良い単体テストがある場合は、長いテストサイクルを開始する前に、システムの品質に関するフィードバックをすばやく得ることができます。
実際には、通常、さまざまなレベルの自動テストを採用しています。
単体テストの問題に関して：
常にリファクタリングしなければならない単体テストは、レベルが低すぎるのではないかと思います。一般に、入力を変化させて低レベルのコードを実行する、やや高レベルのテストを行う方が適切です。
不要なコードがないと仮定すると、より高いレベルのテストでも適切なコード カバレッジが得られるはずです (コードに到達できない場合、なぜコードがそこにあるのでしょうか?)。
機能テストの問題に関して：
代表的なデータ サンプル (または複数) を検討することをお勧めします。そうすれば、既知の入力を取得できるため、予測可能な出力が得られるはずです。
いくつかのタイプのテストを維持するコストが高すぎると感じた場合は、それらを削除することを検討するのが賢明です。統合テストは QA にとってより重要であると思います。1 つのタイプのテスト (単体 vs 統合) しか選択できない場合は、それを選択します。
ただし、最初に、これらのメンテナンスの問題を回避するために単体テストを因数分解する方法があるかどうかを検討することもできます。モックを使い始めたばかりの頃は、適切なバランスを見つけるのに時間がかかりました。私の経験では、（期待を持って）モックをできるだけ避けるのが最善だと思います。ただし、私はモッキング ライブラリを使用しますが、より複雑なモッキングではなく、ほとんどの場合、単純なスタブ用です。興味があれば、私はこれについてしばらく前にブログ記事を書きました。