Birincisi, neredeyse hiçbir zaman orada oturup birim testleri yazmıyorum. Birim testleri, kendi içinde bir amaç değil, bir amaç için araçtır. "Bu kod olması gereken temel görevi yerine getiriyor mu?"
Örneğin, bazı insanlar bir işlev yazacak ve daha sonra birkaç değer üzerinde test etmek ve çalıştığından emin olmak için etkileşimli bir oturum açacaktır:
def fact x
if x == 0
1
else
x * fact(x-1)
end
end
>> fact 10
=> 3628800
>> fact 7
=> 5040
Ama şimdi bir hata keşfediyorsunuz:
>> fact -1
SystemStackError: stack level too deep
from (irb):2:in `fact'
from (irb):5:in `fact'
from (irb):10
Yani düzeltirsiniz:
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
Ama şimdi hala çalıştığından emin olmak için test etmelisiniz:
>> fact 10
=> 3628800
>> fact 7
=> 5040
Gördüğünüz gibi, aynı testleri tekrarlamaya devam ediyorsunuz ... ve sonuçları görsel olarak karşılaştırmanız gerekiyor. Birim testi, bu durumda tekrardan kaçınmanın bir yoludur; ne kadar iş yapmanız gerektiğini azaltır. Ve bu aptalca küçük bir örnek olsa da, gerçek dünyada, manuel olarak test etmek gittikçe daha önemli ve daha zor hale geliyor. Bunun elbette anlamı insanların tek tek bileşenleri test etmemesidir; sadece tüm programı test ediyorlar. Ama sonra böcekler ortaya çıkıyor ve bulmak çok daha zor. Ya da hatalar olur ve giderilir, ancak birileri aynı hatayı tekrar tekrar sunar, çünkü kimse bunun olmadığından emin olmak için bir test örneği eklemedi. Ya da birisi büyük bir koda bakar ve "Bunun ne yapılması gerektiği hakkında hiçbir fikrim yok, çünkü belgelenmediği ve testleri olmadığı için ... Bu hatayı düzeltirsem, ona bağlı başka bir şeyi kıracağım hakkında hiçbir fikrim yok; belki bunu sıfırdan yeniden yazacağım. "
Birim testleri, bu durumlarda tüm ekstra işleri azaltır. Onları eğlenceli hale getirmenin en iyi yolu, insanların değiştirdikleri tüm işleri ve her bir kod parçasının ne yapması gerektiğini bilmekten kaynaklanan ekstra esnekliği anlamalarını sağlamaktır. Bir dereceye kadar, insanların birim testlerin ne kadar önemli olabileceğini anlamak için geniş bir kod tabanı yazma ve sürdürme konusunda biraz daha fazla deneyime sahip olmaları gerekir; tüm kodları bir kez yazdıkları ve atıldıkları bir şeyse, asla tam olarak alamazlar.
Ve ünite testleri, gerçekte çalıştıktan sonra “bildiğiniz” bir koda sahip olduğunuzda ekstra bir angarya olarak yazılmamalıdır. Ünite testleri önce veya en azından söz konusu kodu yazdıktan hemen sonra (bazen önce yazmayı unuttuğunuz için) yazılmalıdır. Buna test odaklı geliştirme denir ve API'larınızı daha iyi hale getirmenize yardımcı olabilir; ilk olarak API'leri uygulayan testleri yazarsanız, kodu yazmadan önce API'lerin nerede bir acı olduğunu öğreneceksiniz ve sadece testleri daha sonra eklemekten çok daha kolay bir şekilde yeniden tasarlayabilirsiniz.
MbUnitKütüphane hayatımı değiştirdi. Otomatik test önemlidir. Otomatik test zaman kazandırır. Otomatik test para tasarrufu sağlar. Otomatik test hayat kurtarabilir. Otomatik test tek yoldur. Otomatik test başka bir güvenlik ağıdır. Büyük bir mimari üzerinde çalışan 50 kişiden biri olduğumda, bir duvarda başka bir tuğla gibi hissediyorum. Birim testleri ile kontrolüm altında.