回答:
単体テストは、なしよりも優れています。だから、それは全か無かの取引ではありません。
あなたの場合、テスト駆動開発は標準ではなかったので、テストがどのように役立つのか不思議に思うでしょう。
あなたが書く将来のコードが（現在の）機能を壊さないことを保証したい-そして、それはあなたのサブケースが役に立つ場所です。よく書かれたテストに合格した場合、ほとんど何も破損していない可能性があります。一緒に来る次の開発者は、テストとドキュメントに感謝します。
まずは、階層化されたアーキテクチャを十分に分割し、データアクセス層を選択し、テストを上（UI層に向けて）行う場合です。プロジェクトにドメインモデルがある場合、TDDのほとんどの候補は、ほとんどのロジックを持っている可能性が高いためです。サービス（またはビジネスロジック）層がドメイン/データアクセス層を呼び出すだけの場合、TDD方式でサービス層を実行しても意味がありません。これらはふわふわしたテストであり、あまり価値がありません。
エマのようなコードカバレッジツールに追加-全体的なテストカバレッジの改善を着実に監視できます。
私は非常に大規模なコードベースに取り組んできましたが、最初は単体テストがありませんでした。数年後、いくつかのプラクティスに従うことで、ほとんどのコードベースがテストでカバーされました。
すべての新しいコードには単体テストが必要です。
変更されたすべてのコードには、単体テストを追加する必要があります。
テストを壊さずに安全に古いコードに追加した方法は、主に次の基本的なアプローチを使用することです。
機能を変更する必要があるコードの小さなセクションを選択します。
変更するコードをテストできるようにするために必要なインターフェイスを紹介します。信頼性の高い非常に小さな変更のシーケンスで構成されるリファクタリング手法を使用してください。可能な場合はツールサポートを使用してください。これを行うには、たとえば、変更するメソッドを独自のオブジェクトに移動/抽出します。変更を定期的にチェックインして、元に戻すことができます。リビジョン管理履歴を確認して、変更を行った方法を定期的にピアレビューします。
テストの追加を妨げている依存関係を解消するために必要な変更を最小限に抑えるようにしてください。
これをもっとやればやるほど簡単になることがわかりました。コードベースに戻るたびに、少しずつ改善されます。
QAテスターに届くバグの数が大幅に減少しました。機能のリグレッションはほとんど前代未聞なので、私たちにとって努力する価値があったと思います。
古いものが何年も正常に機能している場合は、古いものを変更しない限り、ユニットテストを今すぐ作成する必要はありません。とにかく、新しい部品の単体テストを書くことはまったく無意味ではありません。新しい部分はバグを含む可能性が最も高い部分であり、変更またはリファクタリングされる可能性が最も高い部分でもあります。
現在のコードのカバーを開始できます。時間があれば、古いコードのコア機能のカバーを開始できます。また、そのためにPMに余分な時間を求めることができます=）