Yanıtlar:
Testlerinizin nasıl düzenlendiği, bunlara sahip olmanın önemine kıyasla oldukça önemsizdir.
İyi bir test paketi için en önemli şey, tüm işlevselliği kapsamasıdır; bir regresyon kusuru ortaya çıktığında hemen fark edersiniz. Her yöntem için bir test yazma, bir yöntemin her giriş değeri kombinasyonu için bir test veya bu yöntemdeki olası her kod yolu için bir test daha az önemlidir. Bu testleri birkaç veya daha fazla test sınıfında organize etmek daha az önemlidir: bir test takımı her zaman tam olarak başarılı olmalıdır, bu nedenle on yedi testten üç veya ikisinden birini başarısız olup olmadığı önemli değildir - her ikisi de yanlıştır ve sabit.
Elbette, test kodu da koddur, bu nedenle bakımı yapılabilen, modüler vb.Gibi normal en iyi uygulamaları izlemelidir. Ancak bu, test sınıflarının test ettikleri sınıflar. Bahsettiğiniz her iki politika da, bunları tutarlı bir şekilde izlerseniz nerede bulacağınızı hatırlamanıza yardımcı olabilir, ancak bunun için tutarlılık, politika seçiminden daha önemlidir.
Özel sorunuza göre, JUnit kuralı, uygulama sınıflarınız ( Foo1.java, Foo2.java) ve JUnit test sınıfları ( Foo1Test.java, Foo2Test.java) arasında 1: 1 yazışma yapmaktır .
Bununla birlikte, Kilian'ın kullanılabilecek herhangi bir organizasyon şeması üzerinde birim testin ruhunun / hedeflerinin önemini vurgulamasına gönülden katılıyorum. Bazı sözleşmeler seçin ve sözleşmelerinizin garanti altına alındığında istisnalarına izin verirken çoğu zaman bunlara sadık kalın.
Her yöntem için ayrı bir sınıf mı yoksa her gerçek sınıf için sadece bir test sınıfına mı sahip olmak daha iyidir?
Bir sınıfın yöntemleri için ayrı test sınıfları yazmanız gerekiyorsa, yanlış tasarıma sahipsiniz. Yöntemler küçük, okunması kolay, test edilmesi kolay ve değiştirilmesi kolay olmalıdır. Test verileri, alay etme vb. Nedenlerle testler orijinal koddan biraz daha uzun olabilir, ancak önemli ölçüde daha uzun olmamalıdır. Eğer öyleyse, test altındaki sınıfınız çok karmaşıktır ve kesin olarak birden fazla şey yapar ( tek sorumluluk ilkesi ): Tasarımınız üzerinde çalışın.
Hem "yöntem başına bir test sınıfı" hem de "sınıf başına bir test sınıfı" genellikle çok aşırı olduğunu düşünüyorum.
Genel olarak, her test yöntemi / birim testi için bir kontrole sahip olmak istersiniz. Örneğin, bunlar a list.isEmpty = trueve list.Length = 0dolayısıyla davranış başına bir test yöntemi / birim testi olup olmadığını kontrol etmek için birden fazla iddia olabilir .
Bu, davranışı açıklayan bir test yöntemi adı bulmayı kolaylaştırır. Test yöntemlerini bir test sınıfında gruplamak istiyorsunuz, bu yüzden okuduğunuzda test classname.test methodmantıklı. Genellikle, bunlar daha sonra test kurulumuna / fikstürüne yerleştirilmesi kolay olan bazı paylaşılan kurulum kodlarına sahiptir. Test edilen sınıfa bağlı olarak, bu tüm sınıf için bir test sınıfı olabilir ve ayrıca bir yöntem için bir test sınıfı olabilir. Ama genellikle, arada bir yerde olacak.
Normal kodda olduğu gibi, testlerin mümkün olduğunca okunabilir olmasını istersiniz. Bana yardımcı olan, BDD'yi o zaman verilen ya da test kodunu organize etme-düzenleme-eylem-iddia etme tarzını takip etmektir. Bir test sınıfı bunu verebilirdi, bu kurulum. Daha sonra, o sınıftaki her test yöntemi verileni (veya bir kısmını) kullanır ve bir zaman ve bir zamana sahiptir.
Ünite testlerini ayrıca test edilen sınıfın işlevselliğinin nasıl kullanılacağına dair belgeler olarak düşünün. İyi birim testleri ile, kullanmak istediğiniz sınıfın işlevselliğinin nasıl kullanılacağını ve etkilerin tam olarak ne olacağını öğrenmek için testleri okuyabilirsiniz.
Bir şey kırıldığında ve birim testi başarısız olduğunda, neyin kırıldığını anlamanın mümkün olduğunca kolay olmasını istersiniz, test başına bir iddia burada çok yardımcı olur. Bir testte birden fazla iddia varsa, sadece birincisi başarısız olur ve daha sonra yöntem çıkar, bu nedenle ilk testin başarısız olmasını sağlayan şeyi düzeltene kadar aşağıdaki testlerde test edilen diğer davranışın da kırılıp kırılmadığını bilmezsiniz. Bir iddia ile, diğer tüm test yöntemleriniz hala yürütülür ve başarısızlığın derinliğini anlamak çok daha hızlıdır.
Tabii ki, Kilian Foth'a katılıyorum: pratikte, üzerinde çalıştığınız kod için birkaç birim test yaptığınız için şanslı olabilirsiniz. Ve herhangi bir küçük yerelleştirilmiş test hiç bir test olmamasından daha iyidir veya yalnızca yapı sunucusunda çalışan büyük entegrasyon testleri çok zaman alır ve genellikle çok yerel değildir (hatanın nerede olduğunu hızlı bir şekilde söylemezler - siz Üzerinde biraz çalışmalıyız).
Her sınıfın kendi test sınıfına sahip olması doğru olduğunu düşünüyorum. Amaç, hedef sınıfla ilgili tüm birim testleri tek bir test sınıfında merkezileştirmektir. Daha sonra, örneğin, MyClass.javatest sınıfı çağrılır MyClassTest.java.