Jak przeprowadzasz testy jednostkowe metod prywatnych?

Buduję bibliotekę klas, która będzie miała kilka publicznych i prywatnych metod. Chcę mieć możliwość testowania jednostkowego metod prywatnych (głównie podczas opracowywania, ale może to również być przydatne do przyszłego refaktoryzacji).

Jaki jest właściwy sposób to zrobić?

Jeśli używasz .net, powinieneś użyć InternalsVisibleToAttribute .

Jeśli chcesz przetestować metodą prywatną metodę prywatną, coś może być nie tak. Testy jednostkowe (ogólnie) mają na celu przetestowanie interfejsu klasy, co oznacza jej publiczne (i chronione) metody. Możesz oczywiście „zhakować” rozwiązanie tego problemu (nawet jeśli tylko upublicznisz metody), ale możesz też rozważyć:

1. Jeśli metoda, którą chcesz przetestować, naprawdę jest warta przetestowania, warto przenieść ją do własnej klasy.
2. Dodaj więcej testów do metod publicznych, które wywołują metodę prywatną, testując funkcjonalność metody prywatnej. (Jak wskazali komentatorzy, powinieneś to zrobić tylko wtedy, gdy funkcjonalność tych prywatnych metod jest naprawdę częścią publicznego interfejsu. Jeśli faktycznie wykonują funkcje ukryte przed użytkownikiem (tj. Test jednostkowy), prawdopodobnie jest to złe).

Testowanie metod prywatnych może nie być przydatne. Jednak czasami lubię też nazywać metody prywatne metodami testowymi. Przez większość czasu, aby zapobiec duplikacji kodu do generowania danych testowych ...

Microsoft udostępnia w tym celu dwa mechanizmy:

Akcesoria

• Przejdź do kodu źródłowego definicji klasy
• Kliknij nazwę klasy prawym przyciskiem myszy
• Wybierz „Utwórz prywatny akcesor”
• Wybierz projekt, w którym ma zostać utworzony akcesor => Otrzymasz nową klasę o nazwie foo_accessor. Ta klasa będzie generowana dynamicznie podczas kompilacji i upublicznia wszystkich członków publicznie dostępnych.

Jednak mechanizm ten jest czasem nieco trudny do rozwiązania, jeśli chodzi o zmiany interfejsu oryginalnej klasy. Tak więc przez większość czasu unikam tego.

Klasa PrivateObject Innym sposobem jest użycie Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject

// Wrap an already existing instance
PrivateObject accessor = new PrivateObject( objectInstanceToBeWrapped );

// Retrieve a private field
MyReturnType accessiblePrivateField = (MyReturnType) accessor.GetField( "privateFieldName" );

// Call a private method
accessor.Invoke( "PrivateMethodName", new Object[] {/* ... */} );

Nie zgadzam się z filozofią „powinieneś być zainteresowany jedynie testowaniem interfejsu zewnętrznego”. To trochę tak, jakby powiedzieć, że warsztat samochodowy powinien mieć tylko testy, aby sprawdzić, czy koła się obracają. Tak, ostatecznie interesuje mnie zachowanie zewnętrzne, ale podoba mi się to, że moje własne, wewnętrzne testy są bardziej szczegółowe i do rzeczy. Tak, jeśli dokonam refaktoryzacji, być może będę musiał zmienić niektóre testy, ale chyba że jest to ogromny refaktor, będę musiał zmienić tylko kilka, a fakt, że inne (niezmienione) testy wewnętrzne nadal działają, jest doskonałym wskaźnikiem, że refaktoryzacja zakończyła się powodzeniem.

Możesz spróbować objąć wszystkie przypadki wewnętrzne przy użyciu tylko interfejsu publicznego i teoretycznie możliwe jest przetestowanie każdej metody wewnętrznej (lub przynajmniej każdej, która ma znaczenie) całkowicie za pomocą interfejsu publicznego, ale może być konieczne stanie się na głowie, aby osiągnąć to i połączenie między przypadkami testowymi uruchamianymi przez interfejs publiczny a wewnętrzną częścią rozwiązania, które mają przetestować, może być trudne lub niemożliwe do rozpoznania. Po wskazaniu, indywidualne testy, które gwarantują, że wewnętrzna maszyna działa poprawnie, są warte drobnych zmian testowych, które pojawiają się przy refaktoryzacji - przynajmniej takie było moje doświadczenie. Jeśli musisz wprowadzić ogromne zmiany w swoich testach dla każdego refaktoryzacji, to może nie ma to sensu, ale w takim przypadku może powinieneś całkowicie przemyśleć swój projekt.

W rzadkich przypadkach chciałem przetestować funkcje prywatne, zwykle zmodyfikowałem je, aby były chronione, i napisałem podklasę z funkcją publicznego pakowania.

Klasa:

...

protected void APrivateFunction()
{
    ...
}

...

Podklasa do testowania:

...

[Test]
public void TestAPrivateFunction()
{
    APrivateFunction();
    //or whatever testing code you want here
}

...

Myślę, że bardziej fundamentalnym pytaniem powinno być to, dlaczego próbujesz w pierwszej kolejności przetestować metodę prywatną. Jest to zapach kodu, który próbujesz przetestować metodę prywatną za pomocą publicznego interfejsu tej klasy, podczas gdy ta metoda jest prywatna z jakiegoś powodu, ponieważ jest szczegółem implementacji. Należy się tylko przejmować zachowaniem interfejsu publicznego, a nie jego implementacją pod przykryciem.

Jeśli chcę przetestować zachowanie metody prywatnej, używając wspólnych refaktoryzacji, mogę wyodrębnić jej kod do innej klasy (być może z widocznością na poziomie pakietu, więc upewnij się, że nie jest to część publicznego API). Następnie mogę przetestować jego zachowanie w izolacji.

Produkt refaktoryzacji oznacza, że ​​metoda prywatna jest teraz oddzielną klasą, która stała się współpracownikiem oryginalnej klasy. Jego zachowanie zostanie dobrze poznane dzięki własnym testom jednostkowym.

Następnie mogę kpić z jego zachowania, gdy próbuję przetestować oryginalną klasę, dzięki czemu mogę skoncentrować się na przetestowaniu zachowania publicznego interfejsu tej klasy, zamiast testować kombinatoryczną eksplozję publicznego interfejsu i zachowanie wszystkich jego prywatnych metod .

Widzę to analogicznie do prowadzenia samochodu. Kiedy prowadzę samochód, nie jeżdżę z podniesioną maską, więc widzę, że silnik działa. Polegam na interfejsie, który zapewnia samochód, a mianowicie na obrotomierzu i prędkościomierzu, aby wiedzieć, że silnik działa. Polegam na tym, że samochód faktycznie porusza się po naciśnięciu pedału gazu. Jeśli chcę przetestować silnik, mogę to sprawdzić osobno. :RE

Oczywiście bezpośrednie testowanie metod prywatnych może być ostatecznością, jeśli masz starszą aplikację, ale wolałbym, aby starszy kod został ponownie przekształcony, aby umożliwić lepsze testowanie. Michael Feathers napisał świetną książkę na ten właśnie temat. http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052

Typy prywatne, wewnętrzne i prywatni członkowie są z jakiegoś powodu i często nie chcesz z nimi zadzierać bezpośrednio. A jeśli to zrobisz, są szanse, że później zepsujesz, ponieważ nie ma gwarancji, że faceci, którzy utworzyli te zespoły, zachowają prywatne / wewnętrzne implementacje jako takie.

Ale czasami, gdy robię jakieś włamania / eksploracje zestawień skompilowanych lub zestawów stron trzecich, sam chciałem zainicjować klasę prywatną lub klasę z konstruktorem prywatnym lub wewnętrznym. Lub czasami, gdy mam do czynienia ze wstępnie skompilowanymi starszymi bibliotekami, których nie mogę zmienić - w końcu piszę testy przeciwko prywatnej metodzie.

Tak narodził się AccessPrivateWrapper - http://amazedsaint.blogspot.com/2010/05/accessprivatewrapper-c-40-dynamic.html - jest to klasa szybkiego która ułatwi zadanie dzięki dynamicznym funkcjom i refleksji C # 4.0.

Możesz tworzyć typy wewnętrzne / prywatne, takie jak

    //Note that the wrapper is dynamic
    dynamic wrapper = AccessPrivateWrapper.FromType
        (typeof(SomeKnownClass).Assembly,"ClassWithPrivateConstructor");

    //Access the private members
    wrapper.PrivateMethodInPrivateClass();

Możesz przetestować prywatną metodę na dwa sposoby

1. możesz utworzyć instancję PrivateObjectklasy, składnia jest następująca

   PrivateObject obj= new PrivateObject(PrivateClass);
   //now with this obj you can call the private method of PrivateCalss.
   obj.PrivateMethod("Parameters");

2. Możesz użyć odbicia.

   PrivateClass obj = new PrivateClass(); // Class containing private obj
   Type t = typeof(PrivateClass); 
   var x = t.InvokeMember("PrivateFunc", 
       BindingFlags.InvokeMethod | BindingFlags.NonPublic | BindingFlags.Public |  
           BindingFlags.Instance, null, obj, new object[] { 5 });

Użyłem również metody InternalsVisibleToAttribute. Warto również wspomnieć, że jeśli czujesz się niekomfortowo, wprowadzając wewnętrzne metody prywatne, aby to osiągnąć, być może nie powinny one być przedmiotem bezpośrednich testów jednostkowych.

W końcu testujesz zachowanie swojej klasy, a nie jej konkretną implementację - możesz zmienić drugą bez zmiany poprzedniej, a twoje testy powinny zostać zaliczone.

Istnieją 2 rodzaje metod prywatnych. Statyczne metody prywatne i niepasujące metody prywatne (metody instancji). Poniższe 2 artykuły wyjaśniają, w jaki sposób testować jednostkowe metody prywatne na przykładach.

1. Testowanie jednostkowe statycznych metod prywatnych
2. Testy jednostkowe Niestatyczne metody prywatne

MS Test ma wbudowaną ciekawą funkcję, która udostępnia prywatnych członków i metody w projekcie, tworząc plik o nazwie VSCodeGenAccessors

[System.Diagnostics.DebuggerStepThrough()]
    [System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.TestTools.UnitTestGeneration", "1.0.0.0")]
    internal class BaseAccessor
    {

        protected Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject m_privateObject;

        protected BaseAccessor(object target, Microsoft.VisualStudio.TestTools.UnitTesting.PrivateType type)
        {
            m_privateObject = new Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject(target, type);
        }

        protected BaseAccessor(Microsoft.VisualStudio.TestTools.UnitTesting.PrivateType type)
            :
                this(null, type)
        {
        }

        internal virtual object Target
        {
            get
            {
                return m_privateObject.Target;
            }
        }

        public override string ToString()
        {
            return this.Target.ToString();
        }

        public override bool Equals(object obj)
        {
            if (typeof(BaseAccessor).IsInstanceOfType(obj))
            {
                obj = ((BaseAccessor)(obj)).Target;
            }
            return this.Target.Equals(obj);
        }

        public override int GetHashCode()
        {
            return this.Target.GetHashCode();
        }
    }

Z klasami wywodzącymi się z BaseAccessor

Jak na przykład

[System.Diagnostics.DebuggerStepThrough()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.TestTools.UnitTestGeneration", "1.0.0.0")]
internal class SomeClassAccessor : BaseAccessor
{

    protected static Microsoft.VisualStudio.TestTools.UnitTesting.PrivateType m_privateType = new Microsoft.VisualStudio.TestTools.UnitTesting.PrivateType(typeof(global::Namespace.SomeClass));

    internal SomeClassAccessor(global::Namespace.Someclass target)
        : base(target, m_privateType)
    {
    }

    internal static string STATIC_STRING
    {
        get
        {
            string ret = ((string)(m_privateType.GetStaticField("STATIC_STRING")));
            return ret;
        }
        set
        {
            m_privateType.SetStaticField("STATIC_STRING", value);
        }
    }

    internal int memberVar    {
        get
        {
            int ret = ((int)(m_privateObject.GetField("memberVar")));
            return ret;
        }
        set
        {
            m_privateObject.SetField("memberVar", value);
        }
    }

    internal int PrivateMethodName(int paramName)
    {
        object[] args = new object[] {
            paramName};
        int ret = (int)(m_privateObject.Invoke("PrivateMethodName", new System.Type[] {
                typeof(int)}, args)));
        return ret;
    }

Na CodeProject znajduje się artykuł, który krótko omawia zalety i wady testowania metod prywatnych. Następnie udostępnia kod refleksyjny umożliwiający dostęp do metod prywatnych (podobny do kodu podanego powyżej przez Marcusa). Jedyny problem, jaki znalazłem w próbce, to to, że kod nie uwzględnia przeciążonych metod.

Artykuł znajdziesz tutaj:

http://www.codeproject.com/KB/cs/testnonpublicmembers.aspx

Zadeklaruj je internal, a następnie użyj, InternalsVisibleToAttributeaby pozwolić zespołowi testowemu urządzenia je zobaczyć.

Nie używam dyrektyw kompilatora, ponieważ szybko zaśmiecają wszystko. Jednym ze sposobów na złagodzenie tego, jeśli naprawdę ich potrzebujesz, jest umieszczenie ich w częściowej klasie, a twoja kompilacja zignoruje ten plik .cs podczas tworzenia wersji produkcyjnej.

Nie powinieneś testować prywatnych metod swojego kodu. Powinieneś testować „interfejs publiczny” lub API, publiczne rzeczy swoich klas. Interfejs API to wszystkie metody publiczne, które udostępniasz zewnętrznym rozmówcom.

Powodem jest to, że gdy zaczniesz testować prywatne metody i elementy wewnętrzne swojej klasy, łączysz implementację swojej klasy (rzeczy prywatne) z testami. Oznacza to, że kiedy zdecydujesz się zmienić szczegóły implementacji, będziesz również musiał zmienić swoje testy.

Z tego powodu należy unikać używania InternalsVisibleToAtrribute.

Oto świetna rozmowa Iana Coopera na ten temat: Ian Cooper: TDD, gdzie wszystko poszło nie tak

Czasami dobrze jest przetestować prywatne deklaracje. Zasadniczo kompilator ma tylko jedną metodę publiczną: Compile (string outputFileName, params string [] sourceSFileNames). Jestem pewien, że rozumiesz, że trudno byłoby przetestować taką metodę bez testowania każdej „ukrytej” deklaracji!

Dlatego stworzyliśmy Visual T #: aby ułatwić testy. Jest to darmowy język programowania .NET (zgodny z C # v2.0).

Dodaliśmy operatora „.-”. Zachowuje się jak „”. operator, z wyjątkiem tego, że możesz również uzyskać dostęp do dowolnej ukrytej deklaracji z testów bez zmiany czegokolwiek w testowanym projekcie.

Zajrzyj na naszą stronę internetową: pobierz ją za darmo .

Dziwię się, że nikt tego jeszcze nie powiedział, ale rozwiązaniem, które zastosowałem, jest stworzenie statycznej metody wewnątrz klasy w celu przetestowania się. Daje to dostęp do wszystkiego, co publiczne i prywatne do przetestowania.

Ponadto w języku skryptowym (z funkcjami OO, takimi jak Python, Ruby i PHP), możesz wykonać test pliku po uruchomieniu. Fajny szybki sposób upewnienia się, że twoje zmiany niczego nie zepsują. To oczywiście tworzy skalowalne rozwiązanie do testowania wszystkich twoich klas: po prostu uruchom je wszystkie. (możesz to również zrobić w innych językach z pustą nazwą główną, która zawsze uruchamia również swoje testy).

Chcę utworzyć tutaj czytelny przykład kodu, którego można użyć w dowolnej klasie, w której chcesz przetestować metodę prywatną.

W klasie przypadków testowych po prostu uwzględnij te metody, a następnie zastosuj je, jak wskazano.

  /**
   *
   * @var Class_name_of_class_you_want_to_test_private_methods_in
   * note: the actual class and the private variable to store the 
   * class instance in, should at least be different case so that
   * they do not get confused in the code.  Here the class name is
   * is upper case while the private instance variable is all lower
   * case
   */
  private $class_name_of_class_you_want_to_test_private_methods_in;

  /**
   * This uses reflection to be able to get private methods to test
   * @param $methodName
   * @return ReflectionMethod
   */
  protected static function getMethod($methodName) {
    $class = new ReflectionClass('Class_name_of_class_you_want_to_test_private_methods_in');
    $method = $class->getMethod($methodName);
    $method->setAccessible(true);
    return $method;
  }

  /**
   * Uses reflection class to call private methods and get return values.
   * @param $methodName
   * @param array $params
   * @return mixed
   *
   * usage:     $this->_callMethod('_someFunctionName', array(param1,param2,param3));
   *  {params are in
   *   order in which they appear in the function declaration}
   */
  protected function _callMethod($methodName, $params=array()) {
    $method = self::getMethod($methodName);
    return $method->invokeArgs($this->class_name_of_class_you_want_to_test_private_methods_in, $params);
  }

$ this -> _ callMethod ('_ someFunctionName', tablica (param1, param2, param3));

Wystarczy wydać parametry w kolejności, w jakiej pojawiają się w oryginalnej funkcji prywatnej

Dla każdego, kto chce uruchamiać prywatne metody bez zgiełku i bałaganu. Działa to z dowolną strukturą testowania jednostkowego wykorzystującą tylko dobre stare odbicie.

public class ReflectionTools
{
    // If the class is non-static
    public static Object InvokePrivate(Object objectUnderTest, string method, params object[] args)
    {
        Type t = objectUnderTest.GetType();
        return t.InvokeMember(method,
            BindingFlags.InvokeMethod |
            BindingFlags.NonPublic |
            BindingFlags.Instance |
            BindingFlags.Static,
            null,
            objectUnderTest,
            args);
    }
    // if the class is static
    public static Object InvokePrivate(Type typeOfObjectUnderTest, string method, params object[] args)
    {
        MemberInfo[] members = typeOfObjectUnderTest.GetMembers(BindingFlags.NonPublic | BindingFlags.Static);
        foreach(var member in members)
        {
            if (member.Name == method)
            {
                return typeOfObjectUnderTest.InvokeMember(method, BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.InvokeMethod, null, typeOfObjectUnderTest, args);
            }
        }
        return null;
    }
}

Następnie w swoich rzeczywistych testach możesz zrobić coś takiego:

Assert.AreEqual( 
  ReflectionTools.InvokePrivate(
    typeof(StaticClassOfMethod), 
    "PrivateMethod"), 
  "Expected Result");

Assert.AreEqual( 
  ReflectionTools.InvokePrivate(
    new ClassOfMethod(), 
    "PrivateMethod"), 
  "Expected Result");

MbUnit ma ładne opakowanie dla tego, zwanego Odbłyśnikiem.

Reflector dogReflector = new Reflector(new Dog());
dogReflector.Invoke("DreamAbout", DogDream.Food);

Możesz także ustawić i uzyskać wartości z właściwości

dogReflector.GetProperty("Age");

W odniesieniu do „testu prywatnego” zgadzam się, że… w idealnym świecie. nie ma sensu przeprowadzać prywatnych testów jednostkowych. Ale w prawdziwym świecie możesz chcieć napisać prywatne testy zamiast refaktoryzować kod.

Oto dobry artykuł na temat testowania jednostkowego metod prywatnych. Ale nie jestem pewien, co jest lepsze, aby twoja aplikacja została zaprojektowana specjalnie do testowania (to jak tworzenie testów tylko do testowania) lub użyć refleksu do testowania. Jestem pewien, że większość z nas wybierze drugi sposób.

Moim zdaniem powinieneś przetestować tylko publiczny interfejs API swojej klasy.

Upublicznienie metody w celu jej jednostkowego przetestowania powoduje przerwanie enkapsulacji ujawniając szczegóły implementacji.

Dobry publiczny interfejs API rozwiązuje bezpośredni cel kodu klienta i rozwiązuje go całkowicie.

Używam PrivateObject klasę. Ale jak wspomniano wcześniej, lepiej unikać testowania metod prywatnych.

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

CC -Dprivate=public

„CC” to kompilator wiersza poleceń w systemie, którego używam. -Dfoo=barrobi równowartość #define foo bar. Tak więc ta opcja kompilacji skutecznie zmienia wszystkie prywatne rzeczy na publiczne.

Oto przykład, najpierw sygnatura metody:

private string[] SplitInternal()
{
    return Regex.Matches(Format, @"([^/\[\]]|\[[^]]*\])+")
                        .Cast<Match>()
                        .Select(m => m.Value)
                        .Where(s => !string.IsNullOrEmpty(s))
                        .ToArray();
}

Oto test:

/// <summary>
///A test for SplitInternal
///</summary>
[TestMethod()]
[DeploymentItem("Git XmlLib vs2008.dll")]
public void SplitInternalTest()
{
    string path = "pair[path/to/@Key={0}]/Items/Item[Name={1}]/Date";
    object[] values = new object[] { 2, "Martin" };
    XPathString xp = new XPathString(path, values);

    PrivateObject param0 = new PrivateObject(xp);
    XPathString_Accessor target = new XPathString_Accessor(param0);
    string[] expected = new string[] {
        "pair[path/to/@Key={0}]",
        "Items",
        "Item[Name={1}]",
        "Date"
    };
    string[] actual;
    actual = target.SplitInternal();
    CollectionAssert.AreEqual(expected, actual);
}

Sposobem na to jest posiadanie metody protectedi napisanie testowego urządzenia, które dziedziczy testowaną klasę. W ten sposób nie zmieniasz metody public, ale włączasz testowanie.

1) Jeśli masz starszy kod, jedynym sposobem na przetestowanie metod prywatnych jest refleksja.

2) Jeśli jest to nowy kod, masz następujące opcje:

• Użyj odbicia (do skomplikowanego)
• Napisz test jednostkowy w tej samej klasie (powoduje, że kod produkcyjny jest brzydki, ponieważ zawiera również kod testowy)
• Refaktoryzuj i upublicznij metodę w jakiejś klasie util
• Użyj adnotacji @VisibleForTesting i usuń prywatną

Wolę metodę adnotacji, najprostszą i najmniej skomplikowaną. Jedyną kwestią jest to, że zwiększyliśmy widoczność, która moim zdaniem nie stanowi dużego problemu. Zawsze powinniśmy kodować do interfejsu, więc jeśli mamy interfejs MyService i implementację MyServiceImpl, wówczas możemy mieć odpowiednie klasy testowe, czyli MyServiceTest (metody interfejsu testowego) i MyServiceImplTest (testuj metody prywatne). Wszyscy klienci i tak powinni korzystać z interfejsu, więc nawet jeśli widoczność metody prywatnej została zwiększona, nie powinno to mieć znaczenia.

Możesz również zadeklarować go jako publiczny lub wewnętrzny (z InternalsVisibleToAttribute) podczas budowania w trybie debugowania:

    /// <summary>
    /// This Method is private.
    /// </summary>
#if DEBUG
    public
#else
    private
#endif
    static string MyPrivateMethod()
    {
        return "false";
    }

Nadyma kod, ale będzie privatew kompilacji wydania.

Możesz wygenerować metodę testową dla metody prywatnej z Visual Studio 2008. Po utworzeniu testu jednostkowego dla metody prywatnej do projektu testowego dodawany jest folder Odwołania testowe, a do tego folderu dodawany jest moduł dostępu. Accessor jest również określany w logice metody testu jednostkowego. Ten akcesor umożliwia testowi jednostkowemu wywoływanie metod prywatnych w testowanym kodzie. Po szczegóły zajrzyj

http://msdn.microsoft.com/en-us/library/bb385974.aspx

Zauważ również, że InternalsVisibleToAtrribute ma wymaganie, aby twój zespół był silnie nazwany , co stwarza własny zestaw problemów, jeśli pracujesz w rozwiązaniu, które wcześniej nie miało tego wymagania. Używam akcesora do testowania metod prywatnych. Zobacz to pytanie jako przykład tego.