Birim test senaryoları için java doc yorumları yazma

Bence, birim test senaryolarının kendisi kod için bir dokümantasyon görevi görür. Şirketim, birim test senaryolarının üzerine ayrıntılı java doc yorumları yazmamı istiyor. Bunu yapmak gerekli mi? Bunun gibi yorumlar yazıyor musunuz?

unit-testing documentation

— Vinoth Kumar CM
kaynak

Test kodunun iyi yazılmış ve okunabilir olduğunu varsayarsak, test kodundaki bu tür bir yorumun birincil değeri bir niyet beyanıdır .. Bu, size izin verdiği için, kendiniz bile yıllarca kod yazarları için çok değerli olabilir. yazılan kodun yargılanması, yapması gerekeni yapmak ya da test etmesi gereken şeyi test etmektir. İkinci olarak, JAVADOC gibi sistemleri ya da basit bir komut dosyasını kullanarak test adlarını ve yorumları koddan kazımak için, hangi testlere sahip olduğunuz ve ne yaptıkları hakkında hızlı bir dokümantasyon oluşturabilirsiniz.

— Chuck van der Linden

Yanıtlar:

Yaptığım şey JAVADOC-yorumu:

hangi sınıfın birim test edildiğini gösteren sınıf (bu konudaki en iyi uygulama, test senaryosunun adının + "Test" veya + "TestCase" sınıfının adı olması gerektiğini düşündürdüğü halde). Bu, {@link XXXClass} JAVADOC yorumu kullanılarak yapılır
hangi yöntemin test edildiğini belirten yöntemler ({@link XXXClass # method1}). Bazen tüm yolları düzgün sınamak için bir sınıfın bir yöntemi için birden çok test yöntemleri olması gerekir. Bu olduğunda, içinde hangi yolu test ettiğimi belirten bir satır daha yazıyorum (ama asla tek satırlık sözleşmemden uzaklaşmıyorum)

Bunun dışında başka yorum yok. Başka yerlerde dikkatlerini çekmek için Cobertura gibi bir şeyi güzel kod kapsamı grafikleri oluşturmak ve onları bu şekilde mutlu etmek için kullanabilirsiniz :-)

Ek not: Birim test senaryolarından bahsediyorum, eğer entegrasyon test vakalarından bahsediyorsak, neler olduğunu açıklamak için bir veya iki satır daha gerekli olabilir ...

— Jalayn
kaynak

Herhangi bir kod için dokümantasyon gereksinimleri bu sorunun cevaplarında tamamen kapsanmaktadır: Patronum kodumuzun satır satır İngilizce anlatımı istiyor

Orada göreceğiniz cevapların bir özeti olarak, "Durumunuza bağlıdır". Makul (ve teşvik edilen) durumlar ve zamanınızın kaybı olduğu diğerleri vardır.

— blueberryfields
kaynak

Javadoc yorumları ayrı bir referans belgesinde çıkarılabilir ve biçimlendirilebilir, birim testleri yapılamaz. Ayrıca, kelimelerle yazdıklarınızın gerçek koddan farklı olabileceğini ve genellikle gerçek beklenen davranışı kelimelerle açıkladığınızı unutmayın. Hata bulmanın yollarından biri, eşleşmezlerse belgeleri gerçek kodla karşılaştırmaktır - bu bir hata (ikisinde ve bazen de - her ikisi de).

Birim testi belgeleme için değil test içindir. Birim testinin dokümantasyon olarak kullanılması yanlıştır ve yapılmamalıdır.

— littleadv
kaynak

Kod belgelemede iyi bir birim test paketi buldum. Birinin kodunun nasıl kullanılması gerektiğine dair bir referans uygulaması ve kodun bu şekilde kullanıldığında düzgün davrandığının kanıtıdır.

— Bill Michell

@ Fatura - bu konuda hiçbir argüman, yararlı. Uygun belgelerin yerini almaz .

— littleadv

Belgeleriniz için kitleye bağlıdır - ancak bazı durumlarda kesinlikle doğrudur.

— Bill Michell

İdeal olarak birim testleri bir sistemin tek dokümantasyonu olmamalıdır - ancak gerçek dünyada 10 projeden 9'u, herhangi bir dokümantasyona sahip olmanın şanslı sayılabileceği eski kodlarla çalışmaktadır . Ve bu durumda, gerçek kodla tamamen senkronize olmayan bir grup belge üzerinde iyi bir çalışma ve geçen birim testleri tercih ederim. (Evet, Javadoc bile olabilir.)

— Péter Török

@ PéterTörök Evet ... Birkaç farklı işveren, bazı tanınmış şirketler arasında geçiş yaptım. Bir sürü eski kod. Sadece ünite şimdiye testler - olanlar ben yazdım. Yani çok şanslıydın. Gördüğünüz şeyin her yerde olan şey olduğunu varsaymayın. Bir dizi birim testiniz olsa bile ... Doğru olduklarını kim söyledi? Ne yapmaları gerektiğini kim söyledi? Beklenen sonuçların ne olduğunu kim söyledi? Ünite testlerinin senkronize olmadığını neden düşünüyorsunuz? Sadece "geçtikleri" için mi? Saçmalık.

— littleadv