Testler nasıl test edilir?

Kodumuzu daha doğru hale getirmek için test ediyoruz (aslında, yanlış olma olasılığı daha düşüktür ). Bununla birlikte, testler de koddur - hatalar da içerebilirler. Eğer testleriniz bozuksa, kodunuzu daha iyi hale getiremezler.

Testlerde üç olası hata türü düşünebilirim:

1. Mantıksal hatalar, programcı eldeki görevi yanlış anladığında ve testler yapması gerektiğini düşündüğü şeyi yaptığında yanlış olur;

2. Temel test çerçevesindeki hatalar (örneğin, sızdıran alaycı bir soyutlama);

3. Testlerdeki Hatalar: Test, programcının düşündüğünden biraz farklıdır.

Tip (1) hatalarını engellemek imkansız görünüyor (programlayıcı sadece ... daha akıllıca olmadıkça). Ancak, (2) ve (3) izlenebilir olabilir. Bu tür hatalarla nasıl başa çıkıyorsunuz? Onlardan kaçınmak için özel stratejileriniz var mı? Örneğin, yalnızca test yazarının önayarlarını kontrol eden bazı özel "boş" testler yazıyor musunuz? Ayrıca, kırık bir test vakasında hata ayıklamaya nasıl yaklaşıyorsunuz?

Testler zaten test edildi. Testler hatalardan korunan tasarım gereğidir, çünkü test sadece kod ve beklentilerimiz arasındaki farkları tespit eder. Sorun varsa, bir hatamız olur. Hata kodda veya testlerde aynı olasılıkta olabilir.

1. Hem kodunuza hem de testlerinize aynı hatayı eklemenizi önleyen bazı teknikler var:

   1. Müşteri uygulayıcıdan farklı bir kişi olmalıdır.
   2. Önce testleri ve sonra kodu yazın (Test Odaklı Geliştirme'deki gibi).

2. Temel platformu test etmeniz gerekmez. Testler sadece sizin tarafınızdan yazılmış kodu uygulamakla kalmaz, aynı zamanda kodu platformdan da çalıştırır. Test platformunda hata yakalamak istemeseniz de, platformda her zaman bir hatayı gizleyen kod ve testler yazmak çok zordur, başka bir deyişle, hem test / kodunuzda sistematik bir hata olması çok zordur. Platformda ve yarattığınız her testte olasılık azaltılır. Bunu yapmayı deneseydin bile çok zor bir işin olurdu.

3. Testlerde hatalar olabilir, ancak testler geliştirilen kodla test edildiği için genellikle kolayca yakalanırlar. Kod ve testler arasında kendinden zorlama geribildirimi vardır. Her ikisi de belirli bir arabirim çağrısının nasıl davranması gerektiği konusunda öngörüde bulunur. Cevap farklıysa, kodda bir hata olması gerekmez. Testte de bir hata olabilir.

Bireysel testleri olabildiğince küçük (kısa) yapmayı deneyin.

Bu, ilk etapta bir hata yaratma şansını azaltmalıdır. Bir tane oluşturmayı başarsanız bile, bulmak daha kolaydır. Birim testlerinin başarısızlık ve sapmalara karşı düşük toleransla küçük ve spesifik olduğu varsayılmaktadır.

Sonunda, muhtemelen sadece bir deneyim meselesi. Ne kadar çok test yazarsanız, o kadar iyi olursanız, kötü testler yapma şansınız o kadar az olur.

Bir taktik, testi test ettiği koddan önce yazmak ve doğru sebepten önce testin başarısız olmasını sağlamaktır. TDD kullanıyorsanız , en azından bu düzeyde test testi yaptırmanız gerekir.

Bir test odasının kalitesini test etmenin daha ayrıntılı bir yolu mutasyon testi kullanmaktır .

# 1 ve # 3 için: Ünite testleri hiç mantık içermemelidir, eğer öyleyse, muhtemelen ünite testinizde birden fazla şeyi test ediyorsunuzdur. Ünite testi için en iyi uygulama, ünite testi başına sadece bir test yapılmasıdır.

Ünite testleri nasıl iyi yazılacağı hakkında daha fazla bilgi için Roy Osherove tarafından bu videoyu izleyin .

# 1 açısından - Ben bu şeyler için eşleştirmek / kod incelemesi için iyi bir fikir olduğunu düşünüyorum. Ön varsayımları yapmak veya sadece yanlış şeyler yapmak kolaydır, ancak testinizin ne yaptığını açıklamak zorunda kalırsanız, amacın ne olduğunu, yanlış hedefe nişan almayı seçmeniz daha olasıdır.

Ünite testi yapmayı bırakmanın bir noktası olmalı. Çizginin ne zaman çizileceğini bilmeli. Test vakalarını test etmek için test senaryoları yazmalı mıyız? Sınama sınavlarına yazılan yeni sınavlardan ne haber? Onları nasıl test edeceğiz?

if (0 > printf("Hello, world\n")) {
  printf("Printing \"Hello, world\" failed\n");
}

Düzenleme: Yorum tarafından önerilen açıklama ile güncellendi.

Hey.
Başvurular yapmanız gerekiyor:

• Ürününüz
• Bu ürün için testiniz.

Ürününüze karşı testler yaparken, aslında testin kendisinde değil , ürününüz ve testleriniz arasındaki etkileşimde bulunmazsınız . Test başarısız olursa uygulamanın bir hatası olduğunu söylemez. Ürün ve test arasındaki etkileşimin başarılı olmadığını söylüyor . Şimdi neyin yanlış gittiğini belirlemek senin işin. Ya olabilir:

• uygulama beklediğiniz gibi davranmıyor (bu beklenti testinizde ifade edildi)
• uygulama doğru davranıyorsa, bu davranışı doğru şekilde belgelendirmediniz (testlerinizde)

Benim için başarısız testler basit bir geri bildirim değil, bu ve bu yanlış . Bu tutarsızlık göstergesidir ve isteğin yanlış gittiğini kontrol etmek için ikisini de incelemeliyim. Sonunda, uygulamanın doğru olduğunu onaylamaktan sorumluyum, testler, kontrol edilmeye değer alanları vurgulamak için sadece bir araçtır.

Testler sadece uygulamanın bazı kısımlarını kontrol ediyor. Uygulamayı test ederim, testleri test ederim.

Testler böcekleri barındıracak kadar "akıllı" olmamalıdır.

Yazdığınız kod bir takım özellikler uygular. (Eğer X, ardından Y, Z olmadığı sürece Q, vb.). Testin gerçekleştirilmeye çalışılması gereken, Z'nin Z olmadığı sürece X'in gerçekten Y olduğunu belirlemektir. Bu, testin yapması gereken tüm işlemlerin X ayarlanması ve Y'nin doğrulanması anlamına gelir.

Ama bu tüm davaları kapsamıyor, muhtemelen diyorsunuz ve haklısınız. Ancak eğer testi Z ile yapmıyorsanız, X'in sadece Y ile yapması gerektiğini bilecek kadar "akıllı" hale getirirseniz, testte iş mantığını yeniden uygularsınız. Bu, aşağıda biraz daha derinlere ineceğimiz için sorunlu. İlk testinizi "daha akıllı" hale getirerek kod kapsamını iyileştirmemelisiniz, bunun yerine X ve Z'yi ayarlayan ve Q'yi doğrulayan ikinci bir aptal test eklemelisiniz. bazen mutlu yol olarak da bilinir) ve kenar kasayı ayrı bir test olarak kapsayan biri.

Bunun bir çok nedeni vardır, her şeyden önce başarısız bir testin iş mantığındaki bir hatadan mı yoksa testlerdeki bir hatadan mı kaynaklandığını nasıl belirlersiniz? Açıkçası cevap, eğer testler olabildiğince basitse, böcekleri barındırma olasılığı çok düşüktür. Testlerinizin test edilmesi gerektiğini düşünüyorsanız, hatalı test yapıyorsunuzdur .

Diğer nedenler arasında yalnızca çabayı çoğaltmanız (daha önce de belirttiğim gibi, tüm olasılıkları tek bir testte uygulamak için yeterince akıllı bir test yazmak) temel olarak, gereksinimler değişirse o zaman testlerin yeni gereksinimleri yansıtacak şekilde değiştirilmesi kolay olmalı, testler bir tür dokümantasyon görevi görür (test edilen ünitenin spesifikasyonunun ne olduğunu söylemenin resmi bir yoludur), vb.

TL: DR: Testlerinizin test edilmesi gerekiyorsa, yanlış yapıyorsunuz demektir. Aptal testleri yaz .

Cevap değil (yorum yapma yetkisine sahip değilim), ancak test senaryoları geliştirmek için başka nedenleri unuttum mu diye merak ediyordum ...
Testlerdeki tüm hataları bir kez çözdüğünüzde, uygulamanızı kolayca regresyon testine sokabilirsiniz. Otomatik test paketleri entegrasyondan önce sorunları daha önce bulmanıza yardımcı olacaktır. Gereksinimlerdeki değişikliklerin test edilmesi nispeten daha kolaydır, çünkü değişiklikler daha yeni olabilir, eski test vakalarının değiştirilmiş hali ve eski davalar başarısızlıkları tespit etmeye devam eder.

Kısa cevap: Üretim kodu testleri test eder .

Bunu , ekonomide kullanılan kredi / borç modeliyle karşılaştırın . Mekaniği çok basittir - Kredi borçtan farklıysa, yanlış bir şey var.

Aynısı birim testleri için de geçerlidir - Bir test başarısız olursa bir şeyin yanlış olduğunu gösterir. Üretim kodu olabilir, ancak test kodu da olabilir! Bu son kısım önemliyse.

Tip (1) hatalarınızın birim testlerinde bulunamayacağını unutmayın. Bu tür hataları önlemek için başka araçlara ihtiyacınız var.