Bu durumda test başına bir iddiaya uymak aptalca bir tutarlılık mıdır?

Test ettiğim bir sınıfım var. Sınıfın bir işlevi vardır:apply(List<IRule> rules, List<ITarget> targets);

Bir testte, her hedefin bir kurala, bir la'ya aktarıldığından emin olmak istiyorum:

rule1.AssertWasCalled(fnord => fnord.Test(target1));
rule1.AssertWasCalled(fnord => fnord.Test(target2));
rule1.AssertWasCalled(fnord => fnord.Test(target3));

Bana öyle geliyor ki, kendimi tek bir iddia beyanıyla sınırlamak oldukça hobgoblin olurdu . Bu varsayımda doğru muyum, yoksa aslında her hedefin test edildiğini iddia edebileceğim başka bir yol var mı?

Üç varsayım özünde bir testtir. Bir koleksiyondaki bir yöntemin davranışını, her öğenin belirli bir çağrı için bir parametre olduğundan emin olmak için test ediyorsunuz (yani, her bir öğe doğru bir şekilde işlendi).

Verileri üç kez ve üç farklı yöntemle ayarlamak, israfa sahiptir ve birkaç önermeye sahip olmaktan daha az okunabilir.

Tek iddia "kuralı" daha çok, aynı yöntemde (esasen farklı şeyleri test etmek) farklı türlerde varsayımlar yapmakla ilgilidir; bu, tek bir davranış için test ettiğiniz bu durumda gerçekten geçerli değildir.

İnanıyorum ki, test kurallarınıza göre bu bir iddia, testlerinizin tek bir konuya odaklanmasını sağlamak için var. Bir testte 20 şeyi test ederseniz, kapsamınızın ne olduğunu söylemek gerçekten zor. Test yöntemini kelime olmadan ve içinde isimlendiremediğinizde bir soruna neden olduğunu biliyorsunuz . Örneğin, test yönteminiz daha doğru bir şekilde adlandırılırsa testFooIsTrueAndDbExistsAndBarIsNullAndAnExceptionDoesntOccur(), muhtemelen bir testte çok fazla test yapıyorsunuzdur.

Sizin durumunuzda, sanırım üç kez iddia etmek sorun değil. Kodunuzu daha okunabilir hale getirmek istiyorsanız, bu üç eki adlı bir yönteme çıkarabilirsiniz assertWasCalledOnTargets(...).

Belirli bir örnek için, aşağıdaki gibi bir şey yaparsanız "one" assert ifadesi ile kaçabilirsiniz:

foreach target in targets
{
     rule1.AssertWasCalled(fnord => fnord.Test(target))
}

Bir testte birden fazla iddiaya sahip olmaktan suçlu hissetmemek için yaptığım şey bu.

Ben de bununla mücadele ettim.

Sade (içimde) test başına bir iddiada ısrar ediyor, bu yüzden işlerin nerede patladığını * tam olarak * bileceğim .

Ve sonra kendimi aynı, gereksiz test kurulum kodunun birçoğunu kesip yapıştırırken buluyorum. Bunun üçüncü veya dördüncü katmanından sonra “Oy! Yeter!” Demeye başlarsınız.

Uzlaşmam, "asla" kırılmayan yönleri bulmak oldu. Ve ben birlikte bu parçaları katman ve sonra ekleyeceğiz biri kırabilir yeni eleman. Sadece açık olmak gerekirse, bir testte birden fazla uçucu alanın katmanlanması bu uzlaşmanın ihlali olacaktır.

İçin kurulum kodu, kurulum kodundan target1farklıysa target2, bu tür köşe kesme, sonunda aşırı uzun test başlatma koduna yol açma eğilimindedir. Bu da bir karışıklıktır ya da yeniden düzenlenir ve yeniden kullanılır. Testleriniz onları yeniden düzenlemeyi haklı çıkaracak kadar karmaşıksa, testiniz muhtemelen birden fazla şeyi test ediyordur.

Her hedefin kurulum kodu temelde aynı ise, testinizi birden fazla ayrı teste bölmek büyük olasılıkla aşırıdır.

Eğer target1ve target2aynı arayüz farklı uygulamaları vardır, bunun yerine arabirimine bir birim test ekleyerek (ve test çerçevesi o arayüzün her uygulama için bir test oluşturmak için izin) olmalıdır.