Assert.Inconclusive kullanımı

Question

Birisinin Assert.Inconclusive() yöntemini nasıl kullanması gerektiğini merak ediyorum.

Eğer birim testim, testin ne için olduğu dışında bir nedenden dolayı başarısız olmak üzereyse kullanıyorum. Örneğin, bir sınıf dizisinin toplamını hesaplayan bir yönteme sahibim. Aynı sınıfta, elemanın ortalamasını hesaplamak için bir yöntem de vardır. Toplamı arayarak ve dizinin uzunluğuna bölerek uygulanır.

Sum() için bir birim testi yazmak kolaydır. Ancak, Ortalama() ve Sum() için bir sınama yazdığımda başarısız olursa, Ortalama() büyük olasılıkla da başarısız olur.

Ortalama hatası, başarısız olma nedeni hakkında açık değildir; Test etmesi gereken şeyden başka bir nedenden dolayı başarısız oldu. Bu yüzden, Sum() doğru sonucu döndürüp döndürmediğini kontrol ederim, aksi takdirde Assert.Inconclusive().

Bu iyi bir uygulama olarak mı görülmeli? Assert.Inconclusive ne için tasarlanmıştır? Veya önceki örneği bir Yalıtım Çerçevesi aracılığıyla mı çözmeliyim?

Answer 1

Birim testlerini oluşturmak için VS kullandığımda, oluşturulan test yöntemleri için Assert.Inclusive'ı aldım ve genellikle bunları çalıştırdığımda başka bir şeyi de değiştiriyorum. Test sonucundaki Assert.Inconclusive soru işaretlerini, henüz hangi testleri henüz tamamlamadığımı hızlı bir şekilde belirtmek için işaretleyiciler olarak kullanıyorum.

Eh, sadece kullanma şeklim. Adından "Sonuçsuz", sanırım ne anlama geldiğini belgelediğiniz sürece belirsiz durumunuzu belirtmek için kullanabilirsiniz. Bununla birlikte, Average() yönteminizin açıklamasından dolayı, belki de birim testinizin sadece bir "birim", belirli bir senaryoyu kapsayacak kadar atomik olmadığını düşünüyorum. Bazen tek bir yöntem için 2 veya 3 birim test metodu yazarım. Veya, Average() yönteminizi tek sorumlulukları kapsayan daha küçük yöntemlere ayırabilirsiniz. Bu şekilde, birim test etmeden önce Average() bir tanesini bu küçük yöntemleri test edebilirsiniz.

---

Johannes,

Bu benim Sum() ve Average() yöntemlerini uygulamak şekli şöyledir.

public static class MyMath 
{ 
    private static void ValidateInput(ICollection<int> numbers) 
    { 
     if (numbers == null) 
      throw new ArgumentNullException("numbers", "Null input. Nothing to compute!"); 
     if (numbers.Count == 0) 
      throw new ArgumentException("Input is empty. Nothing to compute!"); 
    } 

    public static int Sum(int[] numbers) 
    { 
     ValidateInput(numbers); 

     var total = 0; 
     foreach (var number in numbers) 
      total += number; 

     return total; 
    } 

    public static double Average(int[] numbers) 
    { 
     ValidateInput(numbers); 
     return Sum(numbers)/numbers.Length; 
    } 
} 

Kolaylık olması açısından, sadece ValidateInput(ICollection<int>) yönteminden ArgumentException istisna atar. Ayrıca ValidateInput(ICollection<int>) yönteminde taşma olasılığını kontrol edebilir ve OverflowException kodunu atabilirsiniz.

Bu, Average(int[]) işlevini nasıl test edeceğimi söyledi.

[TestMethod] 
public void AverageTest_GoodInput() 
{ 
    int[] numbers = {1, 2, 3}; 
    const double expected = 2.0; 
    var actual = MyMath.Average(numbers); 
    Assert.AreEqual(expected, actual); 
} 

[TestMethod] 
[ExpectedException(typeof(ArgumentNullException))] 
public void AverageTest_NullInput() 
{ 
    int[] numbers = null; 
    MyMath.Average(numbers); 
} 

[TestMethod] 
[ExpectedException(typeof(ArgumentException))] 
public void AverageTest_EmptyInput() 
{ 
    var numbers = new int[0]; 
    MyMath.Average(numbers); 
} 

Bu sınamalar kurulumunda, tüm sınamalar geçtiğinde, işlevimin doğru olduğundan emin olabilirim. Peki, taşma durumu hariç. Şimdi taşma olup olmadığını kontrol etmek için mantık eklemek için ValidateInput(ICollection<int>) yöntemine geri dönebilirim, ardından taşmaya neden olan girişler için OverflowException'un atılmasını beklemek üzere bir tane daha test daha ekleyebilirim. Ya da TDD'yi kullanarak yaklaşmayı seviyorsanız bunu ters sırayla yapın.

Umarım bu, fikri açıklığa kavuşturmaya yardımcı olur.

Henüz testi yazmadım, ben sadece test yöntemini -veya-

Testim bağımlılığı ve bu bağımlılığı var

oluşturduk:

Answer 2

Ben sadece Assert.Fakat testleri henüz sonuçlanmadı. Bazen bir şey yazarken kaçırmak istemediğim bir köşe davası fark ettim. Bu yüzden hızlıca zıpladım, test yöntemini açıklayıcı bir isimle yazıp tek bir Assert.Inconclusive satırı ekleyin.

Bunu yapmanın nedeni, iş akışımı çok fazla kesintiye uğratmadan test etmem gereken şeylerle ilgili belge sağlamasıdır. Ayrıca, test sonuçlarının hızlı bir şekilde sonuç listesinde filtrelenmesini mümkün kılar. Sonuçsuz bir başarısızlığa sahip olmak, herhangi bir şeyi kırmadığım anlamına geliyor ki, yazacak daha fazla test yapıyorum.

Answer 3

Sonuçsuz test, sonucu belirleyemediğiniz bir testtir. Örneğin, bir tür harici kaynak kullanan bir testiniz varsa (örneğin İnternet bağlantısı). Bağlantı şu anda mevcut değilse, bu gerçekten testin başarısız olduğu anlamına gelmez. Öte yandan, onu gerçekten çalıştırmadan başarılı olarak işaretlememelisiniz. Yani bunu sonuçsuz olarak işaretleyin ve bu test raporunda görülebilir.

NOT: Genel olarak, testlerinizde bu tür harici kaynakları kullanmamalısınız, çünkü bu, testleri kırılgan yapabilir.

Henüz tamamlanmamış testler için, MbUnit'in Explicit özniteliğini kullanıyorum.

Answer 4

Assert.Inconclusive ya belirtir mevcut değil. Örneğin,

List<Customer> custs = o.GetAllCustomers(); 
if (custs.Count == 0) 
{ 
    Assert.Inconclusive("No customers to test"); 
    return; 
}