Çok fazla iddia kodu kokusu var mı?

Birim testlerine ve TDD'ye gerçekten aşık oldum - test enfekte oldum.

Ancak, birim testleri normalde genel yöntemler için kullanılır. Bazen özel yöntemlerde de bazı varsayım-iddiaları test etmem gerekse de, bazıları "tehlikeli" ve yeniden düzenleme daha fazla yardımcı olamaz. (Biliyorum, çerçevelerin test edilmesi özel yöntemlerin test edilmesine izin veriyor).

Böylece özel bir yöntemin ilk ve son satırının her ikisinin de iddia olduğu bir alışkanlık haline geldi.

Ancak, sadece "emin olmak" için kamu yöntemlerinde (özel yanı sıra) iddiaları kullanma eğiliminde olduğunu fark ettim. Genel yöntem varsayımları birim test çerçevesi tarafından dışarıdan test edildiğinden, bu "yineleme testi" olabilir mi?

Birisi kod kokusu olarak çok fazla iddiayı düşünebilir mi?

Bu iddialar varsayımlarınızı test etmek için gerçekten yararlıdır, ancak başka önemli bir amaca da hizmet ederler: belgeler. Herkese açık bir yöntemin herhangi bir okuyucusu, test paketine bakmak zorunda kalmadan, ön ve son koşulları hızlı bir şekilde belirlemek için ekleri okuyabilir. Bu nedenle, bu önerileri test nedenlerinden ziyade dokümantasyon nedenleriyle saklamanızı tavsiye ederim. Teknik olarak iddiaları kopyalıyorsunuz, ancak iki farklı amaca hizmet ediyorlar ve her ikisinde de çok faydalılar.

Onları iddia olarak tutmak sadece yorumları kullanmaktan daha iyidir, çünkü her çalıştırıldığında varsayımları aktif olarak kontrol ederler.

Görünüşe göre el ile Sözleşme Tasarım yapmaya çalışıyorsunuz .

DbC yapmak iyi bir fikirdir, ancak en azından yerel olarak ( Eiffel gibi ) destekleyen bir dile geçmeyi veya en azından platformunuz için bir sözleşme çerçevesi kullanmayı düşünmelisiniz (örn . .NET için Microsoft Code Contractsoldukça güzel, tartışmasız en sofistike sözleşme çerçevesi, Eiffel'den bile daha güçlü). Bu şekilde, sözleşmelerin gücünden daha iyi yararlanabilirsiniz. Mevcut bir çerçeve kullanarak, sözleşmelerinizi belgelerinizde veya bir IDE'de yansıtabilirsiniz (örneğin .NET için Kod Sözleşmeleri IntelliSense'te gösterilir ve VS Ultimate'iniz varsa derleme sırasında otomatik bir teorem uzmanı tarafından statik olarak kontrol edilebilir) Aynı şekilde birçok Java sözleşme çerçevesinin, sözleşmeleri otomatik olarak JavaDoc API belgelerinize çıkaracak JavaDoc dokümanları vardır).

Ve durumunuzda manuel olarak yapmanın bir alternatifi olmadığı ortaya çıksa bile, şimdi en azından ne denildiğini biliyorsunuz ve bunu okuyabilirsiniz.

Kısacası, eğer gerçekten bilmeseniz bile, DbC yapıyorsanız, bu iddialar gayet iyi.

Giriş parametreleriniz üzerinde tam kontrole sahip olmadığınız zaman, basit hataları test etmek çok iyi bir fikirdir. Örneğin null değerinde başarısız.

Onlar kod uygun başarısız olduğunu test etmelisiniz gibi bu testlerinizin çoğaltılması değil verilen kötü girdi parametreleri ve sonra belge olduğunu .

Dönüş parametrelerini iddia etmeniz gerektiğini düşünmüyorum (okuyucunun anlamasını istediğiniz bir değişmeziniz yoksa). Bu aynı zamanda birim testlerin de işi.

Şahsen assertJava'daki ifadeyi sevmiyorum , çünkü kapatılabilirler ve sonra yanlış bir güvenliktir.

Kamu yöntemlerinde iddiaları kullanmanın daha da önemli olduğunu düşünüyorum, çünkü girişleri kontrol etmiyorsunuz ve bir varsayımın kırılma olasılığı daha yüksek olabilir.

Test giriş koşulları tüm kamuya açık ve korunan yöntemlerle yapılmalıdır. Girişler doğrudan özel bir yönteme geçirilirse, girişlerinin test edilmesi gereksiz olabilir.

Test çıktı koşulları (örneğin nesne durumu veya bu dönüş değeri! = Null) iç yöntemlerde (örn. Özel yöntemler) yapılmalıdır. Çıktılar ek hesaplama veya iç durum değişikliği olmadan doğrudan özel bir yöntemden genel bir yöntemin çıktısına geçirilirse, genel yöntemin çıktı koşullarının sınanması gereksiz olabilir.

Ancak Oleksi ile anlaşıyorum, işten çıkarmanın okunabilirliği artırabileceğini ve aynı zamanda sürdürülebilirliği de artırabileceğini kabul ediyorum (eğer doğrudan atama veya geri dönüş artık gelecekte böyle değilse).

İddiaların ve 'uygun' hata / istisna işlemenin nasıl uygulandığının detaylarının cevabı üzerinde etkili olduğu için, bu konuda dil bilincine sahip olmak zor. İşte Java ve C ++ bilgime dayanarak $ 0.02.

Özel yöntemlerle ilgili iddialar, abartıp her yere koymadığınızı varsayarak iyi bir şeydir . Onları gerçekten basit yöntemlere koyuyorsanız veya değişmez alanlar gibi şeyleri tekrar tekrar kontrol ediyorsanız, kodu gereksiz yere karıştırıyorsunuz.

Genel yöntemlerde iddialardan genellikle kaçınılmalıdır. Yine de yöntem sözleşmesinin ihlal edilmediğini kontrol etmek gibi şeyler yapmalısınız, ancak eğer o zaman anlamlı mesajlar, mümkünse durumu geri döndürme vb. İle uygun şekilde yazılmış istisnalar atmalısınız. uygun hata işleme tedavisi ").

Genel anlamda, sadece yardım etmek iddialarını kullanarak olmalıdır sizin ayıklama / gelişmeyi. API'nızı kullananların, kodunuzu kullandıklarında iddiaların etkinleştirileceğini bile varsayamazsınız. Kodu belgelemede bazı faydaları olmasına rağmen, aynı şeyleri belgelemek için genellikle daha iyi yollar vardır (yöntem yöntemi, istisnalar).

(Çoğunlukla) istisnai cevaplar listesine, birçok varsayımın ve çoğaltmanın bir başka nedenine ek olarak, sınıfın yaşam süresi boyunca nasıl, ne zaman ve kim tarafından değiştirileceğini bilmemenizdir. Eğer bir yıl içinde ölecek olan atma kodunu yazıyorsanız, bir endişe değil. 20 yıldan fazla bir süre içinde kullanılacak kodu yazıyorsanız, oldukça farklı görünecektir - ve yaptığınız bir varsayım artık geçerli olmayabilir. Bu değişikliği yapan adam, iddialarınız için size teşekkür edecektir.

Ayrıca, tüm programcılar mükemmel değildir - yine, bu "kayma" lardan birinin çok fazla yayılmayacağı anlamına gelir.

Bu iddiaların (ve varsayımlarla ilgili diğer kontrollerin) bakım maliyetini düşürme üzerindeki etkisini hafife almayın.

Yinelenen ekler olması kendi başına yanlış değil, ama "sadece emin olmak için" iddiaları sahip olmak en iyisi değildir. Her testin tam olarak neyi başarmaya çalıştığına bağlı. Sadece kesinlikle gerekli olanı iddia edin. Bir test, bir yöntemin çağrıldığını doğrulamak için Moq kullanıyorsa, bu yöntem çağrıldıktan sonra ne olacağı önemli değildir, test yalnızca yöntemin çağrıldığından emin olmakla ilgilidir.

Her bir ünite testinde, bir veya iki hariç aynı setler varsa, biraz yeniden düzenleme yaptığınızda, testlerin tümü, size yeniden göstericinin gerçek etkisini göstermek yerine, aynı nedenden dolayı başarısız olabilir. Tüm testleri yaptığınız bir durumla sonuçlanabilir, hepsi başarısız olur, çünkü her test aynı iddialara sahiptir, bu hatayı düzeltirsiniz, testleri tekrar çalıştırır, başka bir nedenle başarısız olurlar, bu hatayı düzeltirsiniz. Tamamlanana kadar tekrarlayın.

Ayrıca test projenizin bakımını da göz önünde bulundurun. Yeni bir parametre eklediğinizde veya çıktı her seferinde hafifçe değiştirildiğinde ne olur, bir grup testten geri dönüp bir onay değiştirmeli ya da bir onay eklemelisiniz? Ve kodunuza bağlı olarak, tüm eklerin başarılı olduğundan emin olmak için çok daha fazla ayar yapmanız gerekebilir.

Birim testine yinelenen ekler eklemek istemenin cazibesini anlayabiliyorum, ama gerçekten aşırıya kaçıyor. İlk test projemle aynı yoldan gittim. Ondan uzaklaştım çünkü tek başına bakım beni deli ediyordu.

Ancak, genel testler için birim testi kullanılır.

Test çerçeveniz erişimcilere izin veriyorsa, özel yöntemleri birim test etmek de iyi bir fikirdir (IMO).

Birisi kod kokusu olarak çok fazla iddiayı düşünebilir mi?

Yaparım. İddialar iyi, ama ilk hedefiniz senaryoyu bile mümkün kılmak değil ; sadece bu değil.

Kötü uygulama.

Herkese açık / özel yöntemleri test etmemelisiniz. Sınıfı bir bütün olarak test etmelisiniz. Sadece iyi bir kapsama sahip olduğunuzdan emin olun.

Her yöntemi ayrı bir kural olarak test etmenin (ilkel) yoluna giderseniz, ileride sınıfınızı yeniden düzenlemenin son derece zor olduğunu göreceksiniz. Ve bu, TDD'nin yapabileceğiniz en iyi şeylerden biri.

Bunun yanı sıra, bir çoğaltma. Ayrıca, kodun yazarının ne yaptığını gerçekten bilmediğini gösteriyor. Ve komik olan şey, biliyorsun .

Bazı insanlar testlerini üretim kodlarından daha az özenle ele alırlar. Olmamalılar. Herhangi bir şey varsa, deneyimlerim testleri daha dikkatli bir şekilde tedavi etmeyi önerir. Buna değerler.