Birim testi - başlarken

Sadece birim testlere başlıyorum ama her şeyin amacını gerçekten anladığımdan emin değilim. Her şey hakkında dersler ve kitaplar okudum, ama sadece iki hızlı sorum var:

1. Birim testinin amacının aslında yazdığımız kodu test etmek olduğunu düşündüm. Bununla birlikte, bana göre, sadece testi çalıştırabilmek için orijinal kodu değiştirmemiz gerekiyor, bu noktada yazdığımız kodu gerçekten test etmiyoruz, test için yazdığımız kodu.

2. Kodlarımızın çoğu harici kaynaklara dayanmaktadır. Bununla birlikte, kodumuzu yeniden düzenlediğimizde, orijinal kodu kıracak olsa bile, harici kaynaklar test senaryolarımızda sadece muck-up olduğundan, testlerimiz hala iyi çalışacaktır. Birim testin amacını bozmuyor mu?

Burada aptalca ses çıkarırsam özür dilerim, ama birinin beni biraz aydınlatabileceğini düşündüm.

Şimdiden teşekkürler.

Benim 0.02 $ ... bu biraz öznel, bu yüzden bir tuz tanesi ile al, ama umarım sana düşündürür ve / veya bazı diyaloglar kıvılcım çıkarır:

1. Ünite testinin benim için temel amacı, yazdığınız kodun kodunuzun yerine getirmesi amaçlanan sözleşmeleri ve uç durumları yerine getirmesini sağlamaktır. Birim testleri uygulandığında, siz (veya gelecekte başka biri) kodunuzu yeniden düzenlediğinde, uygun durum kapsamına sahipseniz kodunuzun tüm harici tüketicilerinin etkilenmemesini sağlamanız daha iyi olabilir. (en azından onların etkilenmemesini istediğiniz derecede).

   Çoğu durumda, hem üretime gönderilebilen hem de kolayca birim testine tabi tutulabilen kod yazabilmelisiniz. Başlamak için iyi bir yer, Bağımlılık Enjeksiyonu kalıplarına ve çerçevelerine bakmak olabilir. (Veya diliniz / seçtiğiniz platform için diğer felsefeler).

2. Harici uygulamaların kodunuzu etkileyebileceği doğrudur. Ancak kodunuzun daha büyük bir sistemin parçası olarak düzgün çalışmasını sağlamak entegrasyon testinin bir fonksiyonudur . (Bu da değişen efor derecelerinde otomatik hale getirilebilir).

   İdeal olarak kodunuz, herhangi bir üçüncü taraf bileşeninin API sözleşmelerine dayanmalıdır; bu, alaylarınız doğru API'yi yerine getirdiği sürece birim testlerinizin hala değer sağladığı anlamına gelir.

   Bu, yalnızca entegrasyon testi lehine birim testinden vazgeçtiğim zamanların olduğunu itiraf edeceğim, ancak bu sadece kodumun kötü belgelenmiş API'lara sahip 3. taraf bileşenlerle çok fazla etkileşime girmesi gereken durumlar oldu. (yani kural yerine istisna).

1. Önce testlerinizi yazmayı deneyin. Bu şekilde, kodunuzun davranışı için sağlam bir tabana sahip olursunuz ve testiniz, kodunuzun gerekli davranışı için bir sözleşme haline gelir. Böylece, testi geçmek için kodu değiştirmek, "testi geçmek için kodu değiştirmek" yerine "test tarafından önerilen sözleşmeyi yerine getirmek için kodu değiştirmek" olur.

2. Saplamalar ve alaylar arasındaki farka dikkat edin. Koddaki herhangi bir değişiklikten etkilenmemesi, saplamaların karakteristik davranışıdır, ancak alay konusu değildir. Sahte tanımıyla başlayalım:

   Mock nesnesi, test koşulları altında gerçek bir nesnenin yerini alır ve bir sistem veya birim testinin bir parçası olarak çağrıların (etkileşimlerin) kendisine karşı doğrulanmasına izin verir.

   -Birlik Test Sanatı

Temel olarak, alaylarınız etkileşimlerinizin gerekli davranışını kontrol etmelidir. Böylece, bir yeniden düzenleme sonra veritabanı ile etkileşim başarısız olursa, sahte kullanarak sınama da başarısız olmalıdır. Bu elbette sınırlamalara sahiptir, ancak dikkatli bir planlama ile alaylarınız sadece "orada oturmaktan" çok daha fazlasını yapar ve "birim testin amacını bozmaz".

İyi bir soru sormak hiçbir şekilde aptal değildir.

Sorularınızı ele alacağım.

1. Birim sınamanın amacı, daha önce yazdığınız kodu sınamak değildir . Zaman kavramı yok. Sadece TDD'de önce test etmeniz gerekiyor, ancak bu kesinlikle herhangi bir birim test için geçerli değildir. Mesele, programınızı sınıf düzeyinde otomatik ve verimli bir şekilde test edebilmektir. Kodu değiştirmek anlamına gelse bile, oraya ulaşmak için yapmanız gerekeni yaparsınız. Ve size bir sır vereyim - bu genellikle anlamına gelir.

2. Bir test yazdığınızda, testinizin doğru olduğundan emin olmak için 2 birincil seçeneğiniz vardır:

   • Her test için girişleri değiştirin
   • Olmasını sağlar programınız düzgün çalıştığından emin bir test durum yaz ve sonra programı sağlayan bir karşılık gelen test durumu yazmak gelmez bu olmamalı şekilde çalışır

   İşte bir örnek:

   TEST(MyTest, TwoPlusTwoIsFour) {
       ASSERT_EQ(4, 2+2);
   }
   
   TEST(MyTest, TwoPlusThreeIsntFour) {
       ASSERT_NE(4, 2+3);
   }
   

   Bunun üzerine, sen birim test eğer mantığı içine senin kod (değil 3. parti kütüphaneleri), o zaman bu bağlamda yaparken, diğer kod kırma konusunda endişe bilmediğimiz ince mükemmel bulunuyor. Temel olarak, mantığınızın, klasik bir test senaryosu olan 3. taraf yardımcı programlarını sarma ve kullanma şeklini test ediyorsunuz.

Sınıf düzeyinde testi tamamladıktan sonra, sınıflarınız (anladığımdan arabulucular) ve 3. taraf kütüphaneler arasındaki entegrasyonu test etmeye devam edebilirsiniz. Bu testlere entegrasyon testi denir ve alayları değil, tüm sınıfların somut uygulamalarını kullanır. Biraz daha yavaş ama yine de çok önemli!

void main()Veritabanı erişiminden çıktı oluşturmaya kadar her şeyi yapan monolitik bir uygulamanız var gibi görünüyor . Doğru birim testine başlamadan önce burada birkaç adım vardır.

1) Birden fazla kez yazılmış / kopyalanmış bir kod parçası bulun. Sadece olsa bile string fullName = firstName + " " + lastName. Bunu aşağıdaki gibi bir yönteme ayırın:

private static string GetFullName (firstName, lastName)
{
    return firstName + " " + lastName;
}

Şimdi önemsiz olsa da, birim test edilebilir bir kod parçanız var. Bunun için bir birim testi yazın. Bu işlemi durulayın ve tekrarlayın. Sonunda bir sürü mantıksal gruplandırılmış yöntemle karşılaşacaksınız ve bundan birkaç sınıf çıkarabilirsiniz. Bu sınıfların çoğu test edilebilir.

Bir bonus olarak, birden fazla sınıf çıkardıktan sonra, onlardan arayüzler çıkarabilir ve programınızı nesnelerin kendileri yerine arayüzlerle konuşacak şekilde güncelleyebilirsiniz. Bu noktada, programı hiç değiştirmeden alaycı / stubbing çerçevesini (hatta kendi elle haddelenmiş sahte ürünlerinizi) kullanabilirsiniz. Veritabanı sorgularını bir sınıfa (veya daha fazlasına) çıkardıktan sonra bu çok kullanışlıdır, çünkü artık sorgunun döndürmesi gereken verileri taklit edebilirsiniz .

Bazı akıllı adamlar "Test etmek zorsa, muhtemelen kötü koddur" dedi. Bu yüzden kodu yeniden yazabilmek, test edebilmek kötü bir şey değil. Harici bağımlılıklara sahip kodlar test etmek ÇOK ZOR, koda bir yükselişi temsil eder ve mümkün olan yerlerde kaçınılmalıdır ve kodunuzun entegrasyonunun belirli alanlarında yoğunlaşmalıdır, fx. cephe / ağ geçidi tipi sınıfları. Bu, dış bileşendeki bir değişiklikle başa çıkmayı çok daha kolay hale getirecektir.