もともと、テストを作成するのは開発者の義務ですが、多くの場合/ e-mature開発者では、これらのケースが80％のカバレッジでさえないことに気付きました。
開発者ではなく、特定のプロジェクトのすべてのテストを作成するQA担当者がいますか？
それに短所はありますか？
回答:
テスト駆動開発では、テストは開発者が作成する必要があります。それ以外の場合は、開発者以外の誰かが開発を推進しています。
そのため、テストを書く仕事を開発者以外に任せるとすぐに、その人は開発者になります。
TDDでの私の経験では、テストコードを書くことは、実稼働コードを書くことと同じくらい難しいことがよくあります。したがって、優れた単体テスト/統合テストコードを記述できるリソースがある場合、それらのテストに合格する本番コードを記述する必要があります。
QAの仕事は、まったく異なる種類のテスト（つまり、使いやすさ/統合テスト）を実行することです。彼らは実際にコードで使用されている技術を知る必要はありません。
コードカバレッジが低いことが心配な場合は、開発者を規律する必要があります。たとえば、コードカバレッジが増加するまで、新しい機能の作業を停止します。一部の組織では、リポジトリにpre-commitフックがあり、カバーされていないコードのチェックインを許可していません。
最後になりましたが、「純粋な」TTDでは、カバーされていないコードはまったくありません（最初にテストを記述するため）。ただし、より低いコードカバレッジが許容される場合があります（人々はそれについて議論しています）。たとえば、POJOのゲッター/セッターのテストを書くのは時間の無駄だと主張する人もいます。
それらのケースは80％のカバレッジすら与えていません
それは管理上の問題かもしれません。
またはそれは無関係かもしれません。
まず、80％と100％のカバー率の違いは、ほとんどコストがかからず、ほとんどメリットがないことです。
「カバレッジ」とは何でも意味します。コードの行、ロジックパスなど。コード行（ロジックパスではない）を意味すると思います。
一部のロジックパスは、「検査」によって非常によくテストされています。コードは明らかであり、if文がなく、複雑さが非常に低く、おそらく追加のテストは必要ありません。
テストを20％増やしても、常に品質が20％向上するとは限りません。
第二に。これは管理上の問題です。経営陣が100％の補償を望んでいる場合、80％の補償を「解放するのに十分」ではなく、100％の補償に報いる報奨制度を導入する必要があります。
より多くのテストを書くためにQAメンバーを追加しても、あまり役に立ちません。
開発者を追加してより多くのテストを記述することは、100％のテストカバレッジを得るために必要なことです。
少なくとも80％のカバレッジが必要な場合は、いくつかのことを行う必要があります。
最後に、意図した実行パスと意図しない実行パスには違いがあることを理解してください。テスト駆動型コードを作成する過程で、独立したifステートメントのペアが必要であることを証明したかもしれません。その結果、使用可能な潜在的な4つの実行パスのうち2つのテストがあります。独立したifステートメントをもう1つ追加すると、8つの実行パスの可能性があります（つまり、指数関数的に上昇します）。
TDDは必ずしも実行のすべての潜在的なパスを予測するわけではないことを理解してください。そのため、完了するために記述する必要があるかもしれないが、そのパスをテストする必要がなかったために記述されていない多くのテストがあります。要するに、TDDはカバレッジを保証しませんが、存在するコードの理由を証明するテストが少なくとも1つあることを保証します。