1つは、ユニットテストを書くことはほとんどありません。単体テストは目的を達成するための手段であり、それ自体が目的ではありません。それらは、「このコードは想定されている基本的なタスクを実行しますか」と答える方法です。
たとえば、一部の人々は関数を記述し、次に対話型セッションを開いていくつかの値でテストし、機能することを確認します。
def fact x
if x == 0
1
else
x * fact(x-1)
end
end
>> fact 10
=> 3628800
>> fact 7
=> 5040
しかし今、バグを発見しました：
>> fact -1
SystemStackError: stack level too deep
from (irb):2:in `fact'
from (irb):5:in `fact'
from (irb):10
あなたはそれを修正します：
def fact x
if x < 0
raise "Can't take the factorial of a negative number"
elsif x == 0
1
else
x * fact(x-1)
end
end
>> fact -1
RuntimeError: Can't take the factorial of a negative number
from (irb):3:in `fact'
from (irb):10
しかし今、あなたは本当にそれがまだ動作することを確認するためにテストすべきです：
>> fact 10
=> 3628800
>> fact 7
=> 5040
ご覧のとおり、同じテストを繰り返し続けます...結果を視覚的に比較する必要があります。この場合、ユニットテストは繰り返しを回避する方法です。必要な作業量が減ります。これは馬鹿げた小さな例ですが、現実の世界では、手動でテストすることがますます重要になり、ますます困難になっています。もちろん、これが意味することは、人々は単に個々のコンポーネントをテストしないということです。プログラム全体をテストするだけです。しかし、その後、バグが発生し、見つけるのがはるかに難しくなります。または、バグが発生し、それらは修正されますが、同じバグが再び発生するのは、それが発生しないことを確認するために誰もテストケースを追加しなかったためです。または誰かが大きなコードを見て、「これが文書化されておらずテストもされていないので、これが何をするのかわからない...」と言います。このバグを修正しても、それに応じて他の何かを壊すかどうかはわかりません。多分私はこれを一から書き直します。」
単体テストは、これらの場合の余分な作業をすべて削減します。それらを楽しくするための最良の方法は、置き換えられる作業のすべてを人々に理解させ、各コードが何をすべきかを知ることからもたらされる追加の柔軟性を確実にすることです。ある程度、人々はユニットテストがどれほど重要かを理解するために、大きなコードベースの作成と保守についてもう少し経験を積む必要があります。すべてのコードが一度書いて捨てたものである場合、彼らはそれを決して得ません。
そして、ユニットテストは事後に書かれてはいけません。あなたが「知っている」コードが既に動作している場合、余分な雑用として。ユニットテストは、問題のコードを記述した直後に、または少なくとも（最初に記述するのを忘れることがあるため）少なくとも最初に記述する必要があります。これはテスト駆動開発と呼ばれ、APIの改善に役立ちます。最初にAPIを実行するテストを作成すると、コードを作成する前にAPIを使用するのが面倒であることがわかり、テストを後で追加する場合よりもはるかに簡単に再設計できます。
MbUnitライブラリには、私の人生を変えました。自動テストは重要です。自動テストにより時間を節約できます。自動テストはお金を節約します。自動テストは命を救うことができます。自動テストが唯一の方法です。自動テストはさらに別の安全策です。私が巨大な建築に取り組んでいる50人のうちの1人であるとき、私は壁にさらに別のレンガのように感じます。単体テストでは、私が管理しています。