Birim testinde ek açıklama olup olmadığını kontrol edebilir miyim?

Abstract sınıfı ve N uzantıları tarafından oluşturulan bir java sınıfı hiyerarşisi var. Soyut sınıfta bir @Remove ek açıklama ile açıklamalı bir yöntem var. Bu ek açıklama kaldırılırsa hızlı bir şekilde başarısız olmayacak istisnalar alamasak da, bellek istisnalarından çıkabiliriz, bu nedenle bu ek açıklama bazı yeniden düzenleme işlemlerinde kaybolursa mümkün olduğunca hızlı fark ettiğimizden emin olmak isterim.

GUTS (iyi birim testleri) oluşturmaya çalışıyorum, bu yüzden testlerimde bu "teknik gereksinimi" belgeleyebileceğimi düşündüm, bunu belirten bir test vakasıyla.

Ancak bu bir özellik değildir, bir uygulama detayıdır ve yöntemin davranışıyla bağlantılı değildir (yöntem boş olabilir, ancak var olması ve açıklanması gerekir).

Bunun için bir test oluşturmak uygun mu veya bu ek açıklamanın varlığını kontrol etmenin başka bir yolu var mı?

Evet, birim testi oluşturun. Ek açıklama kaldırılırsa, üretimdeki bellek hatalarından kurtulabileceğinizi söylüyorsunuz. Bu bir katil böcek olurdu. Testlerin bir şekilde sınırlandırılması gerektiği düşüncesinden dolayı bunun gerçekleşmesine izin vermek karşı üretken. Testler tüm duyularda doğruluğu kontrol etmelidir. Olası sorunu ne kadar erken tespit ederseniz o kadar iyi olur ki, bir birim teste sahip olmak ve CI derlemesinin başarısız olması hatayı önlemenin sağlam yoludur. Böyle bir hatanın ortaya çıkmasını önlemek için başka bir mekanizma icat etmeye çalışmak değerli görünmüyor. Her yeni geliştiriciye, hiçbir işlevsel doğruluk testinin "özel durumu" nu nasıl ele alacağına dair bir açıklama verilmelidir. Bu muhtemelen geliştirici zamanının iyi bir kullanımı değildir.

Düzenleme BDD yapan ekiplerin işletme fonksiyonel testlerini performans testleri gibi teknik testlerden ayırması muhtemeldir. Genellikle ekipler, temel iş mantık testlerinden daha az çalışan entegrasyon testleri de dahil olmak üzere farklı test türlerine sahiptir. Bu genellikle yapı profillerinde yapılır, böylece akışlarındaki geliştiriciler kod işine başlamadan önce hızlı iş mantığı testleri ve daha yavaş entegrasyon testleri yapabilirler. CI derlemesi tüm testleri çalıştıracaktır.

Kritik bir işlev böyle bir bildirici teknik kullanılarak uygulandığında, bildirimi tanıyan çerçevenin bir bölümünü içeren bir bütünleştirme testi kullanmayı tercih ederim. Bu sizi çerçeve davranışındaki değişikliklerden, bildirimin etkisinin yanlış anlaşılmasından vb. Korur. Ek açıklamanın varlığını test etmek belirli bir davranışı garanti etmez.