ユニットテストにどれくらいの時間を費やしていますか？

私が働いていた会社では、経営陣はユニットテストのコードカバレッジが99％以上でなければならないと主張しました。これは、コードよりも多くのテストを書くことになりました。実装に1日かかった単一のクラスのテストを書くのに、文字通り3日かかりました。

しかし、その結果、TDD、テストツール、プラクティスなどについて多くのことを学びました。

私がその後働いた会社では、単体テストは未知のものでした。それは誰かが前に聞いたことがあるかもしれないものでした。単体テストの概念を紹介するのに苦労しましたが、効果はありませんでした。

さて、自営業として、私は疑問に思う-あるどのくらいの時間は本当にユニットテストに費やす必要が？ほとんどがiPhone / Android開発者であるため、コードのどの部分をテストでカバーする必要がありますか？

必要な単体テストの量は、いくつかの要因によって異なります。

• 製品サイズ（プロジェクトが大きいほど、少なくともいくつかの単体テストを含める必要性が大きくなります）
• 必要な品質レベル（可能な限り迅速にリリースする必要があるソフトウェアをすばやくまとめており、いくつかのマイナーなバグが許容される場合、ユニットテストなどのテストをスキップするよう強制される可能性があります）
• 製品のタイプ（UIは単体テストが可能ですが、プロジェクトの重いGUIセクションで単体テストをスキップし、代わりに手動でテストする方が簡単な場合があります）
• コーディング能力/履歴（通常どのような種類のバグを作成しますか？ユニットテストで通常検出されるものですか、それとも別のタイプのテストで通常検出されるものですか。

製品グループでは、単体テストのコードカバレッジを50〜70％、単体テストとテスト自動化の組み合わせで90％以上をカバーしています。単体テストの作成に費やされる典型的な時間は、3〜4日間のヘッドダウンコーディングが必要なすべての機能に対して約1日です。しかし、それは多くの要因によって異なります。

99％のコードカバレッジは素晴らしいです。単体テストは素晴らしいです。しかし、単体テストだけで99％のコードカバレッジは得られますか？単体テストだけで多くのカバレッジを得ることができるとは信じ難いです。

クラスのテストの作成に3日間を費やした場合、それ以外の場合は実装に1日かかりました。なぜこれほど時間がかかったのか、コードを共有したのかについては詳しく説明しませんでした。推測から、私はあなたが実際にあなたのクラスのための本当のユニットテストを書いているのではなく、実際にテスト自動化を書いていたと推測しています。そして、実際には何の問題もありません-2つの異なるタイプのテストの違いを認識している限り。

しかし、あなたは3日間のテストライティングは単一のクラスのためだけだったと言いました。クラス自体が単体テスト用に設計されていない可能性があります。クラスはUIを実装していますか？ネットワーキング？ファイルI / O？その場合、Javaランタイムをテストするために、ランタイムと対話するビジネスロジックよりも多くのコードを書くことになっていた可能性があります。

TDDは、インターフェイスおよび依存関係へのインターフェイスの観点から考えさせます。単一の機能のUI、ネットワーク、およびファイル/ ioを実装する単一のクラスは、複数のクラスに分けて提供する方がよい場合があります-ネットワーク用、ファイル/ io用、UIをモデルビューアーコントローラーデザインに分割します。次に、依存関係の単純なモックオブジェクトを使用して、それぞれに適切なテストを実装できます。もちろん、これにはすべて時間がかかります。したがって、このタイプの設計では、コーディングに1日、テストの作成に3日ではなく、3日間のコーディングと1日間のテストの作成が必要になる場合があります。ただし、コードの保守性と再利用性ははるかに向上します。

単体テストは、メンテナンス時に成果を上げます。長寿命のアプリケーションを計画している場合は、現在考えているよりも多くの時間をメンテナンスに費やすことになります（まだ試していない場合は、成功したプロジェクトがどれくらい長く続くか驚くでしょう）

必要なのは、誤って機能を変更した場合、テストが中断するため、これらのことをできるだけ早く見つけることです。機能が予期せず変更された場合、顧客は強く嫌います。

TDDを実行している場合は、コードと同時にテストを作成し、数分（またはそれ以下）ごとにテストを切り替えます。テストに費やす明確な時間はありません。TDDを使用すると、テスト範囲がしっかりしていることが簡単にわかります。

事後の単体テストの場合、コードが変更のために壊れているかどうかを知らせるテストを作成する必要があります。ここではカバレッジメトリックに依存しませんが、パブリックインターフェイスへのユースケースとパラメーターに基づきます。これは最終的にあなたの良い味と経験に基づいています。

テストに時間を費やさない場合、ライブコードでデバッグするのにさらに時間を費やします。
したがって、テストに必要なだけの時間を費やして、すべて（またはコードの99％）をカバーします。

他の人がすでに指摘したように、それはソフトウェアの種類に大きく依存します。あなたが言及する3：1のテスト/開発時間の比率は、平均的なプロジェクトには少し多すぎるかもしれませんが、ミッションクリティカルなアプリには完全に問題ないかもしれませんし、ライフクリティカルなシステムには少なすぎるかもしれません。

99 +％の単体テストのカバレッジは、平均的なアプリの場合には同様に多すぎるかもしれませんが、ライフクリティカルなプロジェクトには少なすぎます。

私の経験では、量産コードのかなりの部分がエラー処理コードであると考えると、ほとんどのアプリでは80〜90％のカバレッジで十分であり、これには量産コードとほぼ同じ時間の単体テストの記述が必要になる場合があります。（再び、TDD方式で真剣に作業している場合、2つは完全に絡み合って実質的に1つのタスクになるため、実際の比率を推測することしかできません。）