Najlepszy sposób na jednostkowe metody testowe, które wywołują inne metody z tej samej klasy

Niedawno dyskutowałem z przyjaciółmi, która z poniższych 2 metod najlepiej jest usunąć wyniki lub wywołania metod z tej samej klasy z metod z tej samej klasy.

To bardzo uproszczony przykład. W rzeczywistości funkcje są znacznie bardziej złożone.

Przykład:

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

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

Aby to przetestować, mamy 2 metody.

Metoda 1: Użyj funkcji i akcji, aby zastąpić funkcjonalność metod. Przykład:

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);
    }
}

Metoda 2: Uczyń członków wirtualnymi, wyprowadź klasę i skorzystaj z klasy pochodnej Funkcje i akcje zastępujące funkcjonalność Przykład:

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);
    }
}

Chcę wiedzieć, który jest lepszy, a także DLACZEGO?

Aktualizacja: UWAGA: Funkcja B może być również publiczna

Edytowano po oryginalnej aktualizacji plakatu.

Uwaga: nie jest programistą C # (głównie Java lub Ruby). Moja odpowiedź brzmiałaby: w ogóle bym tego nie testował i nie sądzę, że powinieneś.

Dłuższa wersja to: prywatne / chronione metody nie są częściami API, są to po prostu opcje implementacji, które możesz zdecydować o przejrzeniu, aktualizacji lub całkowitym wyrzuceniu bez żadnego wpływu na zewnątrz.

Podejrzewam, że masz test na FunctionA (), która jest częścią klasy widoczną ze świata zewnętrznego. Powinien być jedynym, który ma umowę na wdrożenie (i którą można przetestować). Twoja prywatna / chroniona metoda nie ma umowy na spełnienie i / lub przetestowanie.

Zobacz pokrewną dyskusję tam: https://stackoverflow.com/questions/105007/should-i-test-private-methods-or-only-public-ones

Po komentarzu , jeśli funkcja B jest publiczna, po prostu przetestuję oba za pomocą testu jednostkowego. Możesz myśleć, że test funkcji A nie jest całkowicie „jednostkowy” (jak wywołuje funkcję B), ale nie martwiłbym się tym: jeśli test funkcji B działa, ale nie test funkcji A, oznacza to wyraźnie, że problem nie leży w subdomena FunctionB, która jest wystarczająco dobra dla mnie jako dyskryminatora.

Jeśli naprawdę chcesz całkowicie rozdzielić dwa testy, użyłbym jakiejś techniki kpiny, aby wyśmiewać FunctionB podczas testowania FunctionA (zazwyczaj zwraca ustaloną znaną poprawną wartość). Brakuje mi wiedzy na temat ekosystemu C #, aby doradzić konkretnej kpiącej bibliotece, ale możesz spojrzeć na to pytanie .

Zgadzam się z teorią, że jeśli funkcja jest ważna do przetestowania lub jest ważna do zastąpienia, jest wystarczająco ważna, aby nie być prywatnym szczegółem implementacji testowanej klasy, ale być publicznym szczegółem implementacji innej klasy.

Więc jeśli jestem w scenariuszu, w którym mam

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
     }
}

Potem idę do refaktoryzacji.

class A 
{
     ICollaborator collaborator;

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

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

Teraz mam scenariusz, w którym D () jest niezależnie testowalny i w pełni wymienny.

Jako środek organizacji mój współpracownik może nie żyć na tym samym poziomie przestrzeni nazw. Na przykład, jeśli Ajest w FooCorp.BLL, mój współpracownik może znajdować się na innej głębokiej warstwie, jak w FooCorp.BLL.Collaborators (lub jakakolwiek inna nazwa jest odpowiednia). Mój współpracownik może być ponadto widoczny tylko w zestawie za pomocą internalmodyfikatora dostępu, który następnie ujawnię również projektom testującym moje jednostki za pomocą InternalsVisibleToatrybutu zestawu. Zaletą jest to, że nadal możesz utrzymywać interfejs API w czystości, jeśli chodzi o osoby dzwoniące, jednocześnie produkując weryfikowalny kod.

Dodając do tego, co zauważa Martin,

Jeśli twoja metoda jest prywatna / chroniona - nie testuj jej. Jest to wewnętrzne dla klasy i nie powinno być dostępne poza klasą.

W obu wymienionych przeze mnie podejściach mam obawy -

Metoda 1 - To faktycznie zmienia zachowanie badanej klasy w teście.

Metoda 2 - W rzeczywistości nie testuje kodu produkcyjnego, zamiast tego testuje inną implementację.

W podanym problemie widzę, że jedyną logiką A jest sprawdzenie, czy wynik funkcji B jest parzysty. Mimo że jest to przykładowe, funkcja B podaje wartość losową, którą trudno przetestować.

Oczekuję realistycznego scenariusza, w którym możemy skonfigurować MyClass w taki sposób, abyśmy wiedzieli, jaka funkcja B zwróci. Wtedy nasz oczekiwany wynik jest znany, możemy wywołać FunctionA i potwierdzić rzeczywisty wynik.

Ja osobiście używam Method1, tj. Przekształcam wszystkie metody w Action lub Funcs, ponieważ to znacznie poprawiło dla mnie testowalność kodu. Podobnie jak w przypadku każdego rozwiązania, z tym podejściem wiążą się zalety i wady:

Plusy

1. Pozwala na prostą strukturę kodu, przy czym używanie wzorców kodów tylko do testów jednostkowych może dodatkowo zwiększyć złożoność.
2. Umożliwia zapieczętowanie klas i eliminację metod wirtualnych wymaganych przez popularne frameworki takie jak Moq. Uszczelnianie klas i eliminowanie metod wirtualnych czyni je kandydatami do inlinizacji i innych optymalizacji kompilatora. ( https://msdn.microsoft.com/en-us/library/ff647802.aspx )
3. Upraszcza testowanie, ponieważ zastąpienie implementacji Func / Action w teście jednostkowym jest tak proste, jak tylko przypisanie nowej wartości do Func / Action
4. Pozwala również na sprawdzenie, czy statyczny Func został wywołany z innej metody, ponieważ metod statycznych nie można wyśmiewać.
5. Łatwe refaktoryzacja istniejących metod do Funcs / Actions, ponieważ składnia wywołania metody w witrynie wywołującej pozostaje taka sama. (W przypadkach, gdy nie można zmienić metody na Func / Action, zobacz minusy)

Cons

1. Funkcji / akcji nie można użyć, jeśli można wyprowadzić klasę, ponieważ funkcje / akcje nie mają ścieżek dziedziczenia, takich jak metody
2. Nie można użyć parametrów domyślnych. Utworzenie Func z domyślnymi parametrami pociąga za sobą utworzenie nowego delegata, co może spowodować, że kod będzie mylący w zależności od przypadku użycia
3. Nie można użyć nazwanej składni parametru do wywoływania metod takich jak coś (firstName: „S”, lastName: „K”)
4. Największą wadą jest to, że nie masz dostępu do odwołania „this” w Funcs and Actions, więc wszelkie zależności od klasy muszą zostać jawnie przekazane jako parametry. Jest dobrze, ponieważ znasz wszystkie zależności, ale źle, jeśli masz wiele właściwości, od których będzie zależeć Twój Func. Twój przebieg będzie się różnić w zależności od przypadku użycia.

Podsumowując, korzystanie z testu Funcs and Actions for Unit jest świetne, jeśli wiesz, że twoje klasy nigdy nie zostaną zastąpione.

Ponadto zwykle nie tworzę właściwości Funcs, ale wstawiam je bezpośrednio jako takie

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

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

Mam nadzieję że to pomoże!

Korzystanie z Mock jest możliwe. Nuget: https://www.nuget.org/packages/moq/

I wierz mi, że jest to dość proste i ma sens.

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
    }
}

Mock potrzebuje metody wirtualnej do zastąpienia.