Bu.
Sadece birim sınaması yapsanız bile, sınamalarda gerçekte sınanan koddan daha fazla kod olması olağan değildir. Bunda yanlış bir şey yok.
Basit bir kod düşünün:
public void SayHello(string personName)
{
if (personName == null) throw new NullArgumentException("personName");
Console.WriteLine("Hello, {0}!", personName);
}
Testler ne olurdu? Burada test edilecek en az dört basit vaka vardır:
Kişi adı null. İstisna gerçekten atılmış mı? Yazılacak en az üç satır test kodu.
Kişi adı "Jeff". "Hello, Jeff!"Cevap veriyor muyuz ? Bu dört satır test kodu.
Kişi adı boş bir dizedir. Hangi çıktıyı bekliyoruz? Asıl çıktı nedir? Yan soru: işlevsel gereksinimlere uygun mu? Bu, ünite testi için dört kod satırı daha ifade eder.
Kişi adı bir dize için yeterince kısa, ancak "Hello, "ünlem işareti ile birlikte kullanılamayacak kadar uzun . Ne oldu?
Bu, çok fazla test kodu gerektirir. Ayrıca, en temel kod parçaları genellikle test altındaki kod için gerekli olan nesneleri başlatan kurulum kodunu gerektirir, bu da çoğu zaman saplamalar ve alaylar, vb.
Oran çok büyükse, bu durumda birkaç şeyi kontrol edebilirsiniz:
Testler arasında kod çoğaltması var mı? Test kodunun olması, kodun benzer testler arasında kopyalanması (kopyala yapıştırılması) gerektiği anlamına gelmez: bu tür bir çoğaltma bu testlerin bakımını zorlaştıracaktır.
Gereksiz testler var mı? Genel kural olarak, bir birim testini kaldırırsanız, dal kapsamı düşmelidir. Olmazsa, yollar zaten diğer testlerle kaplandığından teste gerek olmadığını gösterebilir.
Sadece test etmeniz gereken kodu mu test ediyorsunuz? Üçüncü taraf kütüphanelerinin temel çerçevesini test etmeniz beklenmez , yalnızca projenin kodunu yazmanız gerekir.
Duman testleri, sistem ve entegrasyon testleri, fonksiyonel ve kabul testleri ve stres ve yük testleri ile daha da fazla test kodu eklersiniz, bu nedenle gerçek kodun her bir LOC'si için dört veya beş LOC testine sahip olmak endişelenmeniz gereken bir şey değildir.
TDD hakkında bir not
Kodunuzu sınamak için geçen süre konusunda endişeleriniz varsa, yanlış yaptığınız olabilir, ilk önce kod, daha sonra testler. Bu durumda, TDD sizi 15-45 saniyelik tekrarlarla çalışmaya, kod ve testler arasında geçiş yapmaya teşvik ederek yardımcı olabilir. TDD'nin savunucularına göre, yapmanız gereken sınama sayısını ve daha da önemlisi, yazmanız gereken iş kodunu ve özellikle sınama için yeniden yazmayı azaltarak geliştirme sürecini hızlandırır .
Let ¹ n olmak bir dize maksimum uzunluğu . İşe SayHelloyarayarak n - 1 uzunluğunda çalışması gereken bir dizi uzunluğu arayabiliriz . Şimdi, Console.WriteLineadımda, biçimlendirmenin bir istisna ile sonuçlanacak olan n + 8 uzunluğunda bir dizeyle bitmesi gerekir . Muhtemelen, bellek limitleri nedeniyle, n / 2 karakter içeren bir dize bile bir istisnaya yol açacaktır. Sorulması gereken soru, bu dördüncü testin bir birim testi olup olmadığı (biri gibi gözüküyor, ancak kaynaklar açısından ortalama birim testlere göre çok daha yüksek bir etkiye sahip olabilir) ve gerçek kodu veya temel çerçeveyi test ediyor mu?