Testowanie jednostkowe metod prywatnych w C #

Visual Studio umożliwia testowanie jednostkowe metod prywatnych za pomocą automatycznie generowanej klasy akcesorium. Napisałem test prywatnej metody, która kompiluje się pomyślnie, ale kończy się niepowodzeniem w czasie wykonywania. Dość minimalna wersja kodu i testu to:

//in project MyProj
class TypeA
{
    private List<TypeB> myList = new List<TypeB>();

    private class TypeB
    {
        public TypeB()
        {
        }
    }

    public TypeA()
    {
    }

    private void MyFunc()
    {
        //processing of myList that changes state of instance
    }
}    

//in project TestMyProj           
public void MyFuncTest()
{
    TypeA_Accessor target = new TypeA_Accessor();
    //following line is the one that throws exception
    target.myList.Add(new TypeA_Accessor.TypeB());
    target.MyFunc();

    //check changed state of target
}

Błąd środowiska wykonawczego to:

Object of type System.Collections.Generic.List`1[MyProj.TypeA.TypeA_Accessor+TypeB]' cannot be converted to type 'System.Collections.Generic.List`1[MyProj.TypeA.TypeA+TypeB]'.

Zgodnie z intellisense - i stąd sądzę, że kompilator - cel jest typu TypeA_Accessor. Ale w środowisku wykonawczym jest typu TypeA, a zatem dodawanie listy kończy się niepowodzeniem.

Czy jest jakiś sposób, aby zatrzymać ten błąd? Lub, być może bardziej prawdopodobne, jakie inne porady mają inne osoby (przewiduję, że „nie testuj metod prywatnych” i „nie testuj jednostkowo testów stanu obiektów”).

Tak, nie testuj prywatnych metod .... Ideą testu jednostkowego jest przetestowanie urządzenia za pomocą jego publicznego „API”.

Jeśli zauważysz, że musisz przetestować wiele prywatnych zachowań, najprawdopodobniej masz nową „klasę” ukrytą w klasie, którą próbujesz przetestować, wypakuj ją i przetestuj za pomocą publicznego interfejsu.

Jedna rada / narzędzie do myślenia ... Istnieje pomysł, że żadna metoda nigdy nie powinna być prywatna. Oznacza to, że wszystkie metody powinny znajdować się na publicznym interfejsie obiektu .... jeśli uważasz, że musisz ustawić go jako prywatny, najprawdopodobniej żyje on na innym obiekcie.

Ta rada nie sprawdza się w praktyce, ale w większości jest dobrą radą i często zmusza ludzi do rozkładania przedmiotów na mniejsze.

Możesz użyć klasy PrivateObject

Class target = new Class();
PrivateObject obj = new PrivateObject(target);
var retVal = obj.Invoke("PrivateMethod");
Assert.AreEqual(expectedVal, retVal);

„Nic nie jest nazywane standardową lub najlepszą praktyką, prawdopodobnie są to tylko popularne opinie”.

To samo dotyczy również tej dyskusji.

Wszystko zależy od tego, co uważasz za jednostkę, jeśli uważasz, że UNIT jest klasą, trafisz tylko na metodę publiczną. Jeśli uważasz, że UNIT to linie kodu, uderzanie w prywatne metody nie spowoduje, że poczujesz się winny.

Jeśli chcesz wywołać metody prywatne, możesz użyć klasy „PrivateObject” i wywołać metodę invoke. Możesz obejrzeć ten szczegółowy film na youtube ( http://www.youtube.com/watch?v=Vq6Gcs9LrPQ ), który pokazuje, jak używać „PrivateObject”, a także omawia, czy testowanie metod prywatnych jest logiczne.

Inną myślą tutaj jest rozszerzenie testów na „wewnętrzne” klasy / metody, dając więcej białych wrażeń na temat tych testów. Możesz użyć InternalsVisibleToAttribute na zestawie, aby udostępnić je osobnym modułom testującym jednostki.

W połączeniu z zapieczętowaną klasą możesz podejść do takiego enkapsulacji, że metoda testowa jest widoczna tylko z najcichszego zestawu twoich metod. Weź pod uwagę, że chroniona metoda w zamkniętej klasie jest de facto prywatna.

[assembly: InternalsVisibleTo("MyCode.UnitTests")]
namespace MyCode.MyWatch
{
    #pragma warning disable CS0628 //invalid because of InternalsVisibleTo
    public sealed class MyWatch
    {
        Func<DateTime> _getNow = delegate () { return DateTime.Now; };


       //construktor for testing purposes where you "can change DateTime.Now"
       internal protected MyWatch(Func<DateTime> getNow)
       {
           _getNow = getNow;
       }

       public MyWatch()
       {            
       }
   }
}

I test jednostkowy:

namespace MyCode.UnitTests
{

[TestMethod]
public void TestminuteChanged()
{
    //watch for traviling in time
    DateTime baseTime = DateTime.Now;
    DateTime nowforTesting = baseTime;
    Func<DateTime> _getNowForTesting = delegate () { return nowforTesting; };

    MyWatch myWatch= new MyWatch(_getNowForTesting );
    nowforTesting = baseTime.AddMinute(1); //skip minute
    //TODO check myWatch
}

[TestMethod]
public void TestStabilityOnFebruary29()
{
    Func<DateTime> _getNowForTesting = delegate () { return new DateTime(2024, 2, 29); };
    MyWatch myWatch= new MyWatch(_getNowForTesting );
    //component does not crash in overlap year
}
}

Jednym ze sposobów testowania metod prywatnych jest refleksja. Dotyczy to także NUnit i XUnit:

MyObject objUnderTest = new MyObject();
MethodInfo methodInfo = typeof(MyObject).GetMethod("SomePrivateMethod", BindingFlags.NonPublic | BindingFlags.Instance);
object[] parameters = {"parameters here"};
methodInfo.Invoke(objUnderTest, parameters);

Eee ... Przyszedł tutaj z dokładnie tym samym problemem: przetestuj prostą , ale kluczową metodę prywatną . Po przeczytaniu tego wątku wydaje się, że „chcę wywiercić ten prosty otwór w tym prostym kawałku metalu i chcę się upewnić, że jakość odpowiada specyfikacjom”, a potem pojawia się „OK, to nie jest łatwe. Po pierwsze, nie ma do tego odpowiedniego narzędzia, ale możesz zbudować obserwatorium fal grawitacyjnych w swoim ogrodzie. Przeczytaj mój artykuł na stronie http://foobar.brigther-than-einstein.org/ Po pierwsze, oczywiście muszę wziąć udział w niektórych zaawansowanych kursach fizyki kwantowej, wtedy potrzebujesz ton ultra-cool nitrogenium, a następnie, oczywiście, moja książka dostępna w Amazon „...

Innymi słowy...

Nie, najpierw najważniejsze.

Każda metoda, prywatna, wewnętrzna, chroniona, publiczna musi być testowalna. Musi istnieć sposób na wdrożenie takich testów bez takich ceregieli, jak tutaj przedstawiono.

Dlaczego? Właśnie ze względu na wzmianki o architekturze poczynione do tej pory przez niektórych autorów. Być może proste powtórzenie zasad oprogramowania może wyjaśnić pewne nieporozumienia.

W tym przypadku zwykłymi podejrzanymi są: OCP, SRP i, jak zawsze, KIS.

Ale chwileczkę. Pomysł, aby udostępnić wszystko publicznie, jest mniej polityczny i stanowi rodzaj postawy. Ale. Jeśli chodzi o kod, nawet w ówczesnej społeczności Open Source, to nie jest dogmat. Zamiast tego „ukrywanie” czegoś jest dobrą praktyką, aby ułatwić zapoznanie się z pewnym interfejsem API. Ukryłbyś na przykład bardzo podstawowe obliczenia nowego bloku konstrukcyjnego termometru cyfrowego - nie po to, aby ukryć matematykę za rzeczywistą zmierzoną krzywą dla ciekawskich czytników kodów, ale aby zapobiec uzależnieniu kodu od niektórych, być może nagle ważni użytkownicy, którzy nie mogliby się oprzeć użyciu twojego wcześniej prywatnego, wewnętrznego, chronionego kodu do realizacji własnych pomysłów.

O czym mówię

prywatny podwójny TranslateMeasurementIntoLinear (podwójny aktualny pomiar);

Łatwo jest ogłosić Wiek Wodnika lub to, co nazywa się obecnie, ale jeśli mój kawałek czujnika zmieni się z 1.0 na 2.0, implementacja Tłumacz ... może zmienić się z prostego równania liniowego, które jest łatwo zrozumiałe i „ponownie” użyteczny dla wszystkich, do dość wyrafinowanych obliczeń, które wykorzystują analizę lub cokolwiek innego, więc złamałbym kod innej osoby. Dlaczego? Ponieważ nie rozumieli samych zasad kodowania oprogramowania, nawet KIS.

Krótko mówiąc: potrzebujemy prostego sposobu na przetestowanie prywatnych metod - bez zbędnych ceregieli.

Po pierwsze: Szczęśliwego nowego roku wszystkim!

Po drugie: przećwicz lekcje architekta.

Po trzecie: „publicznym” modyfikatorem jest religia, a nie rozwiązanie.

Inną opcją, o której nie wspomniano, jest po prostu utworzenie klasy testu jednostkowego jako elementu potomnego testowanego obiektu. Przykład NUnit:

[TestFixture]
public class UnitTests : ObjectWithPrivateMethods
{
    [Test]
    public void TestSomeProtectedMethod()
    {
        Assert.IsTrue(this.SomeProtectedMethod() == true, "Failed test, result false");
    }
}

Umożliwiłoby to łatwe testowanie prywatnych i chronionych (ale nie odziedziczonych prywatnych) metod, a także pozwoliłoby oddzielić wszystkie testy od rzeczywistego kodu, aby nie wdrażać zestawów testowych w środowisku produkcyjnym. Przełączenie metod prywatnych na chronione byłoby dopuszczalne w wielu odziedziczonych obiektach i jest to dość prosta zmiana.

JEDNAK...

Chociaż jest to interesujące podejście do rozwiązania problemu testowania ukrytych metod, nie jestem pewien, czy zaleciłbym, aby we wszystkich przypadkach było to właściwe rozwiązanie problemu. Wydaje się trochę dziwne wewnętrzne testowanie obiektu i podejrzewam, że mogą istnieć pewne scenariusze, że takie podejście cię wysadzi. (Na przykład niezmienne obiekty mogą utrudnić niektóre testy).

Wspominając o tym podejściu, sugeruję, że jest to raczej sugestia burzy mózgów niż uzasadnione rozwiązanie. Dodaj szczyptę soli.

EDYCJA: Uważam, że to naprawdę zabawne, że ludzie głosują na tę odpowiedź, ponieważ wyraźnie opisuję to jako zły pomysł. Czy to oznacza, że ​​ludzie się ze mną zgadzają? Jestem taki skołowany.....

Z książki Skuteczna praca ze starszym kodem :

„Jeśli musimy przetestować metodę prywatną, powinniśmy ją upublicznić. Jeśli upublicznienie nam to przeszkadza, w większości przypadków oznacza to, że nasza klasa robi zbyt wiele i powinniśmy to naprawić”.

Według autora sposobem na jego naprawienie jest utworzenie nowej klasy i dodanie metody as public.

Autor wyjaśnia dalej:

„Dobry projekt jest testowalny, a projekt, który nie jest testowalny, jest zły”.

Tak więc, w tych granicach, jedyną prawdziwą opcją jest stworzenie metody publicw bieżącej lub nowej klasie.

TL; DR: Wyodrębnij metodę prywatną do innej klasy, przetestuj na tej klasie; czytaj więcej o zasadzie SRP (zasada pojedynczej odpowiedzialności)

Wydaje się, że potrzebujesz wyciągu z privatemetody do innej klasy; w tym powinno być public. Zamiast próbować testować privatemetodę, powinieneś przetestować publicmetodę tej innej klasy.

Mamy następujący scenariusz:

Class A
+ outputFile: Stream
- _someLogic(arg1, arg2) 

Musimy przetestować logikę _someLogic; ale wydaje się, że Class Aodgrywają większą rolę niż to konieczne (narusza zasadę SRP); po prostu podziel na dwie klasy

Class A1
    + A1(logicHandler: A2) # take A2 for handle logic
    + outputFile: Stream
Class A2
    + someLogic(arg1, arg2) 

W ten sposób someLogicmożna przetestować na A2; w A1 po prostu stwórz fałszywy A2, a następnie wstrzyknij do konstruktora, aby sprawdzić, czy A2 jest wywoływany do funkcji o nazwie someLogic.

W VS 2005/2008 możesz użyć prywatnego akcesora do przetestowania prywatnego członka, ale ten sposób zniknął w późniejszej wersji VS