Kara kutu birimi testi nedir?

Son zamanlarda yüksek lisans programım için bir yazılım mühendisliği dersi için final sınavım oldu ve sınavdaki sorulardan biri şuydu:

Unit Testing is considered:
a. White-box Testing
b. Black-box Testing
c. Either

7 yıllık yazılım geliştirme deneyimimde, birim testi her zaman beyaz kutu yaklaşımı benimsedi. Test cihazı, testleri yazarken daima ünitenin uygulanması hakkında tam bilgi sahibi olmuştur. Kara kutu testi her zaman daha sonra entegrasyon, sistem ve kabul testi şeklinde geldi.

Bununla birlikte, sınava doğru cevap (profesöre göre) birim testinin beyaz veya kara kutu testi olabileceğidir.

Bazı araştırmalar yaptım ve birçok durumda "kara kutu birim testi" kod önce kod testleri önce birim testleri yazılan bir test ilk yaklaşımını tanımlamak için kullanılır gibi görünüyor. Ancak bence bu hala beyaz kutu testi. Uygulama henüz mevcut olmasa da, testi yazan kişi genellikle kaynak kodun nasıl uygulanacağı konusunda oldukça iyi bir fikre sahiptir.

Birisi bana kara kutu birim testinin nasıl çalıştığını (gerçekten bir şeyse) ve beyaz kutu birim testinden nasıl farklı olduğunu açıklayabilir mi?

Profesörünüz haklı: birim testi ya kara kutu ya da beyaz kutu olabilir. Fark, test edenin bildikleri hakkında daha az, ancak test senaryolarını nasıl oluşturduğunuz hakkında daha fazladır.

Kara kutu testi ile, yalnızca arayüze ve (varsa) bir bileşenin spesifikasyonuna bakarsınız. Bir fonksiyonun imzası olduğunda int foo(int a, int b), sadece ilginç tamsayıları test ederek birkaç test durumu oluşturabilirim: sıfır, bir, eksi bir, çok basamaklı sayılar, INT_MAX, INT_MAX - 1 vb. Kara kutu testleri harika çünkü uygulamadan bağımsızlar. Ancak önemli vakaları da kaçırabilirler.

Beyaz kutu testiyle, uygulamaya, yani kaynak koduna bakıyorum ve bundan test senaryoları üretiyorum. Örneğin, bir işlev için% 100 yol kapsamı elde etmek isteyebilirim. Daha sonra tüm yolları almak için girdi değerlerini seçiyorum. Beyaz kutu testleri harikadır, çünkü kara kutu testlerinden çok daha fazla güvenle bir kod parçasını kapsamlı bir şekilde kullanabilirler. Ancak, aslında önemli davranışları değil, yalnızca uygulama ayrıntılarını test ediyor olabilirler. Bazı durumlarda, açıkça zaman kaybıdır.

Beyaz kutu testi uygulamadan türetildiğinden, ancak daha sonra yazılabilir. Bir kara kutu testi tasarım / arayüz / spesifikasyondan türetilir ve bu nedenle uygulamadan önce veya sonra yazılabilir. TDD ne açıkça kara kutu, ne de beyaz kutu. Tüm davranışlar ilk önce bir testle ifade edildikten sonra bu davranış için minimum kod uygulandığından, TDD beyaz kutu testine benzer test senaryoları ile sonuçlanır. Ancak bilgi akışına baktığımızda, TDD testleri kaynak kodundan değil, harici gereksinimlerden türetilir. Bu nedenle, TDD daha kara kutuya benzer.

Test Odaklı Geliştirme gerçekleştiriyorsanız, teorik olarak tüm birim testleriniz kara kutu olmalıdır. Bu sizin "önce test yaklaşımınız" dır. Sözleşmeyi (arayüz) yazar, o sözleşmenin testlerini yazarsınız ve daha sonra sözleşme uygulama tarafından yerine getirilir. Bu nedenle test, uygulama hakkında hiçbir şey bilmez ve hiçbir şey bilmemelidir.

Sonuçta, bir test yazdığınızda, ne test ediyorsunuz? Genel yöntemler / işlevler.

Bir sınıf için arabirimi yazıp testleri yazsaydınız ve sonra bir otobüse çarptıysanız, hastanedeyken sınıfı yazan kişi bunu arayüzünüzden yapabilmelidir, değil mi? Onu atmak ve kendi arayüzünü ve testlerini yazmak zorunda olmamalıdır.

Bu biraz ayrı düşerse, uygulamanın bağlı olduğu bir şeyle alay etmeniz gerektiğinde, ancak kendinizi kamuya asla maruz kalmayan bir şeyi alay ettiğiniz durumda bulursanız, bir hata yaptınız ve yapmanız gereken Bağımlılık Enjeksiyonu ve ark . Bu nedenle, siyah değil, beyaz kutu birim testinin istisna olması gerektiğini savunuyorum.

Bir sınıfın uygulamasının değiştirildiği ancak testlerin hala geçerli olması gereken 'Tuvalet - Test Davranışı Uygulamada Değil'i düşünün .

Bununla birlikte, kod kapsamınızın açık olduğundan emin olmanız gerekiyorsa (yani, tüm koşullu yolların uygulama içinde test edildiğinden emin olun), kesinlikle ünite testini beyaz kutuya almanız gerekir, çünkü tek yol sizin yollar uygulamadaki yollara bakarak.

İyi yazılmış tüm birim testlerinin doğal olarak "kara kutu" olduğunu iddia ediyorum. Elbette testi yazarken aklımda bir uygulama olabilir, ancak yeniden düzenleme yaptığımda bu uygulama değişebilir. Bu nedenle test, uygulamayı değil işlevselliği test etmek için test sırasında yalnızca genel API'ları kullanmalıdır. Uygulama ayrıntılarını umursamıyor, bu yüzden kara kutu testi.

Test edilen birimin iç veya özel yönlerine erişen testler yazarsam, uygulama ayrıntılarını test ediyorum: Beyaz kutu testiyim. Ancak uygulama değiştiğinde kolayca kırılabilecek kırılgan testler de yazıyorum. Bu yüzden beyaz kutu testleri kötü bir fikirdir ve kaçınılmalıdır.

Sonuç: birim testleri ile beyaz kutu testi yaparsanız, kötü yapılandırılmış testleriniz vardır. Sadece bu birim testleri ile geri kutu testi. Profesör doğru: her ikisi de olabilir. Ama sadece kötü yapılırsa.

Sadece kara kutu testi yapan birim testleri yazma sürecindeydim. Yani, bir sınıfta genel yöntemleri test ediyorum ve aradıkları özel yöntemlerde sonuç test mantığını ima ederek.

Bunu, birim test edilen kamusal yöntemin girdilerini değiştirerek ve destekleyici özel yöntemlerde mantık tarafından belirlenen veya mutasyona uğramış beklenen çıktıları test ederek, uygulanması "birim testlerim" hakkında hiçbir şey bilmemesi gereken bir şey yapıyorum.

Yani, birim testleri üzerinde kara kutu testi yapmayı durduran hiçbir şey yoktur ve birisi gizli destek mantığının uygulanmasıyla uğraşırsa testler kırılacaktır. Aslında, bu, bir sınıftaki her şeyi onun adına test etmek için beyaz kutu ünitesinden daha üstün, daha verimli bir yaklaşım gibi görünüyor. Profesör ile birlikteyim.