さて、3番目のステップに直接進む方がはるかに簡単ではなく、BooksLimit（）の単体テストをまったく行わないでください。
はい...テストの作成に時間を費やさなければ、テストの作成に費やす時間が少なくなります。デバッグに多くの時間を費やすため、プロジェクト全体に時間がかかる可能性がありますが、マネージャーに説明する方が簡単かもしれません。もしそうなら...新しい仕事を手に入れよう！ソフトウェアに対する信頼を高めるには、テストが不可欠です。
単体テストは、コードが多い場合に最大の価値をもたらします。ユニットテストを行わなくても、いくつかのクラスを使用して簡単な宿題を簡単にデバッグできます。世界に出て、数百万行のコードベースで作業していると、それが必要になります。デバッガーをすべてのステップで実行することはできません。あなたは単にすべてを理解することはできません。あなたはあなたが仕事に依存しているクラスを知る必要があります。誰かが「私はこの振る舞いにこの変更を加えるつもりです...私はそれが必要だからです」と言うかどうかを知る必要がありますが、彼らはその振る舞いに依存する他の200の用途があることを忘れています。ユニットテストはそれを防ぐのに役立ちます。
メンテナンスを難しくすることに関して：まさか！ 私はそれを十分に活用することができません。
あなたがあなたのプロジェクトに取り組んだ唯一の人なら、そうです、あなたはそう思うかもしれません。しかし、それはクレイジーな話です！ユニットテストなしで30kラインプロジェクトのスピードを上げてみてください。単体テストなしでコードに大幅な変更を必要とする機能を追加してみてください。自信がない他のエンジニアによる暗黙の仮定を破っていないこと。メンテナ（または既存のプロジェクトの新しい開発者）にとって、単体テストが重要です。私は、ドキュメンテーション、振る舞い、仮定、何かを壊したときのことを教えてくれるユニットテストに頼ってきました（私は無関係だと思っていました）。APIの記述が不十分な場合、テストの記述が不十分であり、テストが常に無駄になるため、変更するのが悪夢になることがあります。最終的には、このコードをリファクタリングして修正したいと思うでしょうが、ユーザーもそれを感謝します。そのため、APIははるかに使いやすくなります。
カバレッジに関する注記：
私にとって、それは約100％のテストカバレッジではありません。100％のカバレッジではすべてのバグが検出されるわけではありません。次の、2つのifステートメントを持つ関数について考えてみます。
// Will return a number less than or equal to 3
int Bar(bool cond1, bool cond2) {
int b;
if (cond1) {
b++;
} else {
b+=2;
}
if (cond2) {
b+=2;
} else {
b++;
}
}
ここで、次のテストを行うテストを作成することを検討してください。
EXPECT_EQ(3, Bar(true, true));
EXPECT_EQ(3, Bar(false, false));
それは100％のカバレッジです。これも契約を満たさない関数ですBar(false, true);。4を返すため失敗します。したがって、「完全なカバレッジ」は最終目標ではありません。
正直なところ、私はのテストをスキップしますBooksLimit()。定数を返すので、それらを書くのに時間をかける価値はないでしょう（そして書くときにテストする必要がありますDisplayBooks()）。誰かが棚のサイズからその制限を（誤って）計算することを決定し、それがもはや私たちの要件を満たさなくなったとき、私は悲しいかもしれません。私は以前に「テストする価値がない」ことでやけどを負ったことがあります。昨年、同僚に「このクラスはほとんどデータであり、テストする必要はありません」と言ったコードを書きました。方法がありました。バグがありました。それは生産に行きました。それは真夜中に私たちを呼び出しました。私は愚かでした。だから私はテストを書きました。そして、私は、どのコードが「テストする価値がない」と構成されているかについて、長く懸命に考えました。あまりありません。
したがって、はい、いくつかのテストをスキップできます。100％のテストカバレッジは素晴らしいですが、それはあなたのソフトウェアが完璧であることを魔法のように意味するものではありません。それはすべて、変化に直面したときの自信に帰着します。
をまとめて、うまくいかないものを見つけた場合、class A3つすべてのデバッグに時間を費やしたいですか？いいえ。私はそれを知りたいのですが、すでに（ユニットテストを介して）彼らの契約を満たしていて、私の新しいコードはおそらく壊れています。だから私はそれをユニットテストします。ユニットテストを行わないと、壊れていることをどうやって知ることができますか？いくつかのボタンをクリックして新しいコードを試してみませんか？それは良いことですが、十分ではありません。プログラムがスケールアップすると、すべての手動テストを再実行して、すべてが正しく機能することを確認することはできなくなります。そのため、単体テストを行う人は通常、テストの実行も自動化します。「合格」または「不合格」と言ってください。「出力は...」とは言わないでください。class Bclass CABclass C
OK、もう少しテストを書いてみよう...