単体テストと呼ばれる機能テストに対する適切な単体テストの具体的な利点は何ですか

私が取り組んでいるプロジェクトには、適切にモックアウトされなかった多数のレガシーテストがあります。このため、それが持つ唯一の依存関係はEasyMockであり、静的、引数付きのコンストラクターなどをサポートしていません。代わりに、テストはデータベース接続などに依存してテストを「実行」します。これらのケースを処理するためにpowermockを追加することは、それをサポートするために既存のプロジェクトをアップグレードする必要があるため、法外なコストとして撃ち落とされています（別の議論）。

私の質問は、プッシュバックに使用できる適切な単体テストの実際の具体的なメリットは何ですか？いずれかがあります？ユニットテストがうまくいかなくても、ユニットテストが悪いのは悪いことだと私は言っているだけですか？コードカバレッジは同じくらい効果的ですか？

• 資源

  テストを実行するには、テストデータベースが必要です。データベースを実行するためのハードウェアは、powermockを使用するよりも高価です。データベースに対する単体テストに使用されるリソースを解放することで、会社はサーバーをすぐにアップグレードする必要がなくなります。

• 信頼性

  データベースがダウンしているか、不整合な状態にあるため、テストが失敗する可能性があります。DBAが日中にいくつかのアップグレードを行うために開発サーバーをダウンさせたため、ビルドは失敗しました（そして今、開発者はコードで何が問題だったかを理解しようとしています-コードではない場合）。

• 追加のメンテナンス

  テストは任意の順序で実行できます。テストを追加または削除しても、テストスイートが失敗することはありません。データベースに対して実行するとは、（データベース内の）どこかに状態があることを意味します。通常、これらのテストでは、データベースが次のテストを実行するための適切な状態を維持するように、追加のメンテナンスが必要です。

• 並行性

  2人の開発者がユニットテストを同時に実行します。データベースがあることは、テストがデータベースで衝突する可能性があることを意味します。これに対する解決策は、実行されるテストごとにデータベースを複製することです。これは、実際のデータベースでは禁止されています。検討すべき別のオプションにつながります。

使用しているデータベースの方言でHSQLDBを使用することも検討してください。このようにして、テストごとにメモリ内データベースを作成できます。単体テストが実行され、必要なデータベースが構築され、データが読み込まれ、コードからのデータベース接続がHSQLDBに接続され、テストデータに対して実行されます。

私の質問は、プッシュバックに使用できる適切な単体テストの実際の具体的なメリットは何ですか？

適切な単体テストは次のとおりです（Clean Codeごとなど）：

• 速い
• 独立した
• 繰り返し可能
• 自己検証
• タイムリーな

真の単体テストがないと、最初の3つ（通常は最後の1つ）に違反します。これはいくつかのかなり重大な問題につながります：

1. テストが遅い。遅いテストはまれにしか実行されません。実行されないテストはほとんど役に立ちません。
2. テストしているコードとは無関係の理由でテストが失敗する可能性があります。これにより、テストが失敗した理由を見つけることがはるかに困難になり、時間を浪費し、コードではなく環境を非難するようになります。
3. データベースが変化すると、結果も変化します。テストのためにデータベースを一貫性のある既知の良好な状態に維持することは、面倒で煩わしく、エラーが発生しやすくなります。

一般に、単体テストに分離性がないと、テストの品質が低下し、コードの作成、調査に時間がかかり、コードベースの信頼性が低下します。その結果、人々はより少ないテストを書くか、より多くのテストを無視することにつながります。これはカオスへの下降スパイラルです。

単体テストは、開発者が信頼できるコードを提供するのに役立つツールにすぎません。上司が考えるように考えれば、提案していることが理にかなっているなら、あなたは彼を説得することができるでしょう。ただし、バンドワゴンでエバンジェリストとして提示した場合、リソースは割り当てられません。レガシーアプリケーションにユニットテストを改良するために時間とリソースを費やすことで、彼がどのように利益を得るかを彼に説明する必要があります。

あなたはレガシーテストについて言及しました-それはレガシーコードを意味します。残念ながら、単体テスト用に設計されていないコードに単体テストを適合させることは、困難で、時間と費用がかかるプロセスです。有用な結果を提供するテストがある場合、ビジネスケースはさらに難しくなり、達成するのは（ビジネスケースのPOVから）同じ結果を提供する代替テストだけです。あなたはコスト（時間）節約に焦点を当てる必要があります.....

私には、ビジネスケースがないため、上司に強力なビジネスケースを提示できないと思います。

あなたが説明したことから、テストフレームワークAが好きではなく、テストフレームワークBに切り替えたいと思われますが、どちらも機能します。それを吸い上げて、既存のものと機能しているものを使用します。好みのテストフレームワークを使用できるように、ホイールを再発明する作業をこれ以上作成しないでください。

ユーザーの利益を本質的にゼロにするために、既存の動作中のコードを破棄し、膨大な時間とお金を費やすことを正当化するために、月フレームワークの最新のフレーバーを使用したいというだけでは不十分です。

優れた単体テストはローカリゼーションを提供します。機能テストでは「ユーザー追加機能が壊れています」と表示される場合がありますが、適切な単体テストでは、誰かがデータベースのUSER.LAST_NAMEフィールドをnull以外に変更したため、壊れていることがわかります。複雑なテスト環境を必要とせずに、小さな変更を直接テストすることもできます（一部のテストでは、再初期化またはパージが必要になる場合があります）。