あなたはユニットテストにどれくらいの時間を費やしていますか？
かつて私が働いていた会社では、幹部はユニットテストでのコードカバレッジは99％以上でなければならないと主張しました。これにより、コードよりも多くのテストが記述されました。実装に1日かかった単一のクラスのテストを書くのに、文字通り3日かかりました。
しかしその結果、TDD、テストツール、プラクティスなどについて多くのことを学びました。
後に働いた会社では、単体テストは未知のものでした。それは誰かが以前聞いたことがあるかもしれません。ユニットテストの概念を紹介するのに苦労しましたが、効果はありませんでした。
今、自営業者として、ユニットテストに費やすには本当にどのくらいの時間が必要なのでしょうか。ほとんどがiPhone/Android開発者なので、コードのどの部分をテストでカバーする必要がありますか？
必要な単体テストの量は、いくつかの要因によって異なります。
- 製品サイズ（プロジェクトが大きいほど、少なくともいくつかの単体テストを含める必要性が高くなります）
- 必要な品質レベル（可能な限り迅速にリリースする必要があるソフトウェアを迅速にまとめており、いくつかのマイナーなバグが許容できる場合は、単体テストなどの一部のテストをスキップしなければならない場合があります）
- 製品のタイプ（UIは単体テストできますが、プロジェクトの重いGUIセクションでの単体テストをスキップして、手動でテストする方が簡単な場合があります）
- あなたのコーディング能力/履歴（通常、どのような種類のバグを作成しますか？ユニットテストが通常キャッチするものですか、それとも別のタイプのテストが通常見つけるものですか。これを知っていると、ユニットテストを行う必要が生じることがあります）
単体テストはメンテナンス時に効果を発揮します。長期にわたるアプリケーションを計画している場合は、今よりも長い時間をかけて維持する必要があります（まだこれを試していない場合は、プロジェクトが成功するまでにどれほどの時間がかかるかがわかります）
あなたが望むのは、誤ってchange機能をテストした場合、テストが中断するため、これらのことを可能な限り速く見つけることができるということです。機能が予期せず変更された場合、顧客は強く嫌います。
私たちの製品グループでは、単体テストの50〜70％のコードカバレッジと、単体テストとテストの自動化を組み合わせた90％以上のカバレッジを目標としています。単体テストの作成にかかる通常の時間は、3〜4日のヘッドダウンコーディングが必要なすべての機能で約1日です。しかし、それは多くの要因によって異なる可能性があります。
99％のコードカバレッジは素晴らしいです。ユニットテストは素晴らしいです。しかし、単体テストだけで99％のコードカバレッジはどうですか？ 単体テストだけでこれだけの報道が得られるとは信じがたいと思います。
実装に1日かかったクラスのテストを3日間書いた場合。なぜこんなに時間がかかるのか、コードを共有する理由については詳しく説明していません。推測から、クラスの真の単体テストを実際に作成したのではなく、実際にtest Automationを作成していたと思います。そして、実際には何も問題はありません-2つの異なるタイプのテストの違いを認識している限り。
しかし、あなたは、3日間のテストライティングは単一のクラスのためだけであると言いました。おそらく、クラス自体は単体テスト用に設計されていません。クラスはUIを実装していますか？ネットワーキング？ファイルI/O？その場合、ランタイムとやり取りするビジネスロジックよりも多くのコードを記述して、Javaランタイムをテストすることになった可能性があります。
TDDを使用すると、インターフェースおよび依存関係へのインターフェースの観点から考えることができます。単一の機能のUI、ネットワーキング、およびファイル/ ioを実装するその単一のクラスは、複数のクラスに分割して提供する方がよい場合があります。次に、依存関係の単純なモックオブジェクトを使用して、それぞれに適切なテストを実装できます。もちろん、これらすべてに時間がかかります。したがって、このタイプの設計では、コーディングに1日、テストに3日かかるのではなく、コーディングに3日、テストに1日かかることが必要になる場合があります。しかし、コードは保守性と再利用性に優れています。
TDDを実行している場合は、コードと同時にテストを作成し、数分（またはそれ以下）ごとにテストを切り替えます。テストに費やされる明確な時間はありません。 TDDを使用すると、テストカバレッジがしっかりしていることが簡単にわかります。
事後の単体テストの場合は、変更が原因でコードが壊れているかどうかを通知するテストを作成する必要があります。ここではカバレッジ指標に依存しませんが、パブリックインターフェースへのユースケースとパラメーターに基づいて行きます。これは、最終的にはあなたの良い味と経験に基づいています。
テストに時間を費やさない場合は、ライブコードでデバッグするためにより多くの時間を費やすことになります。
すべて（またはコードの99％）をカバーするために、テストに必要な時間を費やしてください。
他の人がすでに述べたように、それはソフトウェアのタイプに大きく依存します。言及した3：1のテスト/開発時間の比率は、平均的なプロジェクトには少なすぎるかもしれませんが、ミッションクリティカルなアプリには完全に問題なく、ライフクリティカルなシステムには少なすぎるかもしれません。
同様に、99 +％の単体テストカバレッジは、平均的なアプリの場合には期待するには多すぎるかもしれませんが、生命に関わるプロジェクトには少なすぎます。
私の経験では、量産コードの大部分がエラー処理コードであることを考えると、ほとんどのアプリでは80〜90％のカバレッジで十分であり、これには、量産コードとユニットテストの作成に費やす時間とほぼ同じ時間が必要になる可能性があります。 （繰り返しになりますが、TDDの方法で真剣に作業している場合、2つは完全に絡み合って実質的に1つのタスクになるため、実際の比率を推測することしかできません。）