Aynı sınıf içinde diğer yöntemleri çağıran en iyi test yöntemi yöntemi

Geçenlerde bazı arkadaşlarla tartışarak geri dönüş sonuçlarını saptamak için en iyi olan aşağıdaki 2 yöntemden hangisinin aynı sınıf içindeki yöntemlerden aynı sınıf içindeki yöntemlere çağrı yapmaktan bahsediyordum.

Bu çok basitleştirilmiş bir örnek. Gerçekte, işlevler çok daha karmaşıktır.

Örnek:

public class MyClass
{
     public bool FunctionA()
     {
         return FunctionB() % 2 == 0;
     }

     protected int FunctionB()
     {
         return new Random().Next();
     }
}

Bunu test etmek için 2 yöntemimiz var.

Yöntem 1: Yöntemlerin işlevselliğini değiştirmek için İşlevler ve İşlemler'i kullanın. Örnek:

public class MyClass
{
     public Func<int> FunctionB { get; set; }

     public MyClass()
     {
         FunctionB = FunctionBImpl;
     }

     public bool FunctionA()
     {
         return FunctionB() % 2 == 0;
     }

     protected int FunctionBImpl()
     {
         return new Random().Next();
     }
}

[TestClass]
public class MyClassTests
{
    private MyClass _subject;

    [TestInitialize]
    public void Initialize()
    {
        _subject = new MyClass();
    }

    [TestMethod]
    public void FunctionA_WhenNumberIsOdd_ReturnsTrue()
    {
        _subject.FunctionB = () => 1;

        var result = _subject.FunctionA();

        Assert.IsFalse(result);
    }
}

Yöntem 2: Üyeleri sanal hale getirin, sınıfı türetin ve türetilmiş sınıfta işlevselliği değiştirmek için İşlevler ve Eylemler kullanın Örnek:

public class MyClass
{     
     public bool FunctionA()
     {
         return FunctionB() % 2 == 0;
     }

     protected virtual int FunctionB()
     {
         return new Random().Next();
     }
}

public class TestableMyClass
{
     public Func<int> FunctionBFunc { get; set; }

     public MyClass()
     {
         FunctionBFunc = base.FunctionB;
     }

     protected override int FunctionB()
     {
         return FunctionBFunc();
     }
}

[TestClass]
public class MyClassTests
{
    private TestableMyClass _subject;

    [TestInitialize]
    public void Initialize()
    {
        _subject = new TestableMyClass();
    }

    [TestMethod]
    public void FunctionA_WhenNumberIsOdd_ReturnsTrue()
    {
        _subject.FunctionBFunc = () => 1;

        var result = _subject.FunctionA();

        Assert.IsFalse(result);
    }
}

Hangisinin daha iyi olduğunu ve niçin olduğunu bilmek istiyorum.

Güncelleme: NOT: FunctionB ayrıca herkese açık olabilir

Orijinal poster güncellemesinden sonra düzenlenir.

Feragatname: C # programcısı değil (çoğunlukla Java veya Ruby). Cevabım şöyle olurdu: Ben hiç sınamadım ve yapmam gerektiğini sanmıyorum.

Uzun versiyon şudur: özel / korumalı yöntemler API'nin bir parçası değildir, bunlar temelde uygulama seçenekleridir, dışarıdan herhangi bir etki yapmadan tamamen gözden geçirme, güncelleme veya atma kararı alabilirsiniz.

Sanırım sınıfın dış dünyadan görülebilen bir parçası olan FunctionA () hakkında bir testiniz var. Uygulanması gereken bir sözleşmesi olan (ve test edilebilecek) tek kişi bu olmalıdır. Özel / korumalı yönteminizin yerine getirmek ve / veya test etmek için hiçbir sözleşmesi yoktur.

İlgili bir tartışmaya bakın: https://stackoverflow.com/questions/105007/should-i-test-private-methods-or-only-public-ones

Yorumdan sonra , eğer FunctionB halka açıksa, her ikisini de test kullanarak test edeceğim. FunctionA testinin tamamen "ünite" olmadığını düşünebilirsiniz (FunctionB adını verdiği gibi), ancak bunun için çok endişelenmemeliyim: FunctionB testi işe yararsa ancak FunctionA testi değilse, sorunun açıkça olmadığı anlamına gelir. Bir ayrımcı olarak benim için yeterince iyi olan FunctionB alt alanı.

İki testi gerçekten tamamen ayırabilmek istiyorsanız, FunctionA'yı test ederken FunctionB ile alay etmek için bir tür alaycı teknik kullanırdım (tipik olarak, bilinen bir sabit doğru değer döndürürüm). Belirli bir alaycı kütüphaneyi tavsiye edecek C # ekosistemi bilgim yok ama bu soruya bakabilirsiniz .

Bir fonksiyonun test edilmesi ya da değiştirilmesi önemliyse, test edilen sınıfın özel bir uygulama detayı olmamak, farklı bir sınıfın genel uygulama detayı olmak için yeterince önemli olduğu teorisine katılıyorum.

Öyleyse sahip olduğum bir senaryodaysam

class A 
{
     public B C()
     {
         D();
     }

     private E D();
     {
         // i actually want to control what this produces when I test C()
         // or this is important enough to test on its own
         // and, typically, both of the above
     }
}

Sonra ben refactor'a gidiyorum.

class A 
{
     ICollaborator collaborator;

     public A(ICollaborator collaborator)
     {
         this.collaborator = collaborator;
     }

     public B C()
     {
         collaborator.D();
     }
}

Şimdi D () nin bağımsız olarak test edilebilir ve tamamen değiştirilebilir olduğu bir senaryo var.

Bir organizasyon aracı olarak, ortak çalışanım aynı ad alanı seviyesinde olmayabilir . Örneğin, AFooCorp.BLL'deyse, ortak çalışanım FooCorp.BLL.Collaborators'da olduğu gibi derin bir başka katman olabilir (veya hangi adı uygunsa). İşbirlikçim, daha internalsonra InternalsVisibleTomontaj niteliğindeki ünite test projelerime de maruz kalacağım erişim değiştiricisi aracılığıyla yalnızca montaj içinde görülebilir . Paket servisi doğrulayan kod üretirken, arayanlar söz konusu olduğunda API'nizi hala temiz tutabilirsiniz.

Martin’in neye işaret ettiğini ekleyerek,

Metodunuz özel / korumalı ise - test etmeyin. Sınıfın içindedir ve sınıf dışında erişilmemelidir.

Bahsettiğiniz her iki yaklaşımda da bu endişeler var -

Yöntem 1 - Bu aslında sınama sınama davranışını sınıf değiştirir.

Yöntem 2 - Bu aslında üretim kodunu test etmiyor, bunun yerine başka bir uygulamayı test ediyor.

Belirtilen problemde, A'nın tek mantığının, FunctionB çıktısının eşit olup olmadığını görmek olduğunu görüyorum. Açıklayıcı olmasına rağmen, FunctionB test edilmesi zor olan Rasgele bir değer verir.

FunctionB'in döneceğini bilecek şekilde MyClass'ı ayarlayabileceğimiz gerçekçi bir senaryo bekliyorum. O zaman beklenen sonucumuz bilinir, FunctionA olarak adlandırabilir ve fiili sonucu iddia edebiliriz.

Şahsen Metod1'i kullanıyorum, yani bütün metotları Eylemler veya Fonksiyonlar haline getirerek yaptığım için kod test edilebilirliği oldukça arttı. Herhangi bir çözümde olduğu gibi, bu yaklaşımın avantajları ve dezavantajları vardır:

Artıları

1. Yalnızca Birim Testi için Kod Paternlerinin kullanılmasının ek karmaşıklık sağlayabileceği basit kod yapıları sağlar.
2. Sınıfların mühürlenmesini ve Moq gibi popüler alaycı çerçevelerin gerektirdiği sanal yöntemlerin ortadan kaldırılmasını sağlar. Sınıfların kapatılması ve sanal yöntemlerin ortadan kaldırılması, satır içi ve diğer derleyici optimizasyonlarına aday olmalarını sağlar. ( https://msdn.microsoft.com/en-us/library/ff647802.aspx )
3. Bir Birim testinde Func / Action uygulamasını değiştirmek yerine test edilebilirliği basitleştirir, Func / Action'a yeni bir değer vermek kadar basit
4. Ayrıca, statik yöntemlerin alamadığı için statik bir Func'un başka bir yöntemden çağrılıp çağrılmadığını test etmeye izin verir.
5. Çağrı sitesindeki bir yöntemi çağırmak için kullanılan sözdizimi aynı kaldığından, mevcut yöntemleri Funcs / Actions'a yeniden yansıtmak kolaydır. (Bir yöntemi Func / Action içine yeniden uygulayamadığınız zamanlar için eksilerini görün)

Eksileri

1. Sınıfınız Funcs / Action'lar olarak türetilebilirse Funcs / Actions kullanılamazsa Yöntemler gibi miras yolları yoktur
2. Varsayılan parametreler kullanılamaz. Varsayılan parametrelere sahip bir Func oluşturmak, kullanım durumuna bağlı olarak kodun kafasını karıştıracak yeni bir temsilci oluşturmayı gerektirir.
3. Adlandırılmış parametre sözdizimini bir şey gibi yöntemler çağırmak için kullanılamaz (firstName: "S", lastName: "K")
4. En büyük Con, Funcs ve Actions'daki 'this' referansına erişiminiz olmadığı ve bu nedenle sınıfa bağımlılıkların açıkça parametre olarak iletilmesi gerektiğidir. Tüm bağımlılıkları bildiğiniz gibi iyidir ancak Func'unuzun dayanacağı birçok özelliğe sahipseniz kötüdür. Kilometreniz kullanım durumunuza göre değişecektir.

Özetlemek gerekirse, sınıflarınızın asla geçersiz kılınmayacağını biliyorsanız, Ünite Testi için Funcs ve İşlemleri kullanmak harikadır.

Ayrıca, genellikle Func'lar için özellikler oluşturmaz, ancak bunları doğrudan bu gibi satır içi

public class MyClass
{
     public Func<int> FunctionB = () => new Random().Next();

     public bool FunctionA()
     {
         return FunctionB() % 2 == 0;
     }
}

Bu yardımcı olur umarım!

Mock kullanarak mümkün. Nuget: https://www.nuget.org/packages/moq/

İnan bana oldukça basit ve mantıklı.

public class SomeClass
{
    public SomeClass(int a) { }

    public void A()
    {
        B();
    }

    public virtual void B()
    {

    }
}

[TestFixture]
public class Test
{
    [Test]
    public void Test_A_Calls_B()
    {
        var mockedObject = new Mock<SomeClass>(5); // You can also specify constructor arguments.
        //You can also setup what a function can return.
        var obj = mockedObject.Object;
        obj.A();

        Mock.Get(obj).Verify(x=>x.B(),Times.AtLeastOnce);//This test passes
    }
}

Sahte geçersiz kılmak için sanal yöntem gerekir.