Как вы тестируете приватные методы?

Я строю библиотеку классов, которая будет иметь несколько открытых и закрытых методов. Я хочу иметь возможность тестировать приватные методы модульно (в основном при разработке, но также это может быть полезно для будущего рефакторинга).

Как правильно это сделать?

Если вы используете .net, вы должны использовать InternalsVisibleToAttribute .

Если вы хотите выполнить модульное тестирование частного метода, возможно, что-то не так. Модульные тесты (вообще говоря) предназначены для тестирования интерфейса класса, то есть его открытых (и защищенных) методов. Конечно, вы можете «взломать» решение этой проблемы (даже если просто сделаете методы общедоступными), но вы также можете рассмотреть:

1. Если метод, который вы хотите протестировать, действительно стоит протестировать, возможно, стоит перенести его в свой собственный класс.
2. Добавьте больше тестов к открытым методам, которые вызывают приватный метод, тестируя функциональность частного метода. (Как отметили комментаторы, вы должны делать это только в том случае, если функциональность этих частных методов действительно является частью открытого интерфейса. Если они фактически выполняют функции, скрытые от пользователя (то есть модульное тестирование), это, вероятно, плохо).

Это может быть бесполезно для тестирования частных методов. Однако мне также иногда нравится вызывать закрытые методы из тестовых методов. Большую часть времени, чтобы предотвратить дублирование кода для генерации тестовых данных ...

Microsoft предоставляет два механизма для этого:

Accessors

• Перейти к исходному коду определения класса
• Щелкните правой кнопкой мыши на названии класса
• Выберите «Создать частный доступ»
• Выберите проект, в котором должен быть создан метод доступа => В результате вы получите новый класс с именем foo_accessor. Этот класс будет динамически генерироваться во время компиляции и будет доступен всем доступным членам.

Однако этот механизм иногда немного усложняется, когда дело доходит до изменений интерфейса исходного класса. Поэтому в большинстве случаев я избегаю этого.

Класс PrivateObject Другой способ - использовать 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[] {/* ... */} );

Я не согласен с философией «вас должно интересовать только тестирование внешнего интерфейса». Это все равно, что сказать, что в автосервисе должны быть только тесты, чтобы увидеть, вращаются ли колеса. Да, в конечном счете, я заинтересован во внешнем поведении, но мне нравятся мои собственные, частные, внутренние тесты, чтобы они были более конкретными и конкретными. Да, если я проведу рефакторинг, мне, возможно, придется изменить некоторые тесты, но если это не масштабный рефакторинг, мне придется изменить только некоторые из них, и тот факт, что другие (неизменные) внутренние тесты все еще работают, является отличным показателем того, что рефакторинг прошел успешно.

Вы можете попытаться охватить все внутренние случаи, используя только общедоступный интерфейс, и теоретически возможно полностью протестировать каждый внутренний метод (или, по крайней мере, каждый существенный), используя общедоступный интерфейс, но вам, возможно, придется стоять на голове, чтобы достичь это и связь между тестовыми примерами, выполняемыми через открытый интерфейс, и внутренней частью решения, которое они предназначены для тестирования, могут быть трудными или невозможными для распознавания. Указав, что отдельные тесты, которые гарантируют, что внутренний механизм работает должным образом, стоят тех незначительных изменений, которые произошли с рефакторингом - по крайней мере, это был мой опыт. Если вам нужно вносить огромные изменения в свои тесты для каждого рефакторинга, то, возможно, это не имеет смысла, но в этом случае, возможно, вам следует полностью переосмыслить свой дизайн.

В тех редких случаях, когда я хотел протестировать закрытые функции, я обычно модифицировал их для защиты, и я написал подкласс с функцией публичной оболочки.

Класс:

...

protected void APrivateFunction()
{
    ...
}

...

Подкласс для тестирования:

...

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

...

Я думаю, что должен быть задан более фундаментальный вопрос: почему вы пытаетесь сначала протестировать приватный метод? Это запах кода, когда вы пытаетесь протестировать закрытый метод через открытый интерфейс этого класса, тогда как этот метод является частным по причине, так как это деталь реализации. Нужно заботиться только о поведении открытого интерфейса, а не о том, как он реализован под прикрытием.

Если я хочу проверить поведение закрытого метода, используя обычные рефакторинги, я могу извлечь его код в другой класс (возможно, с видимостью на уровне пакета, поэтому убедитесь, что он не является частью общедоступного API). Затем я могу проверить его поведение в изоляции.

Продукт рефакторинга означает, что закрытый метод теперь является отдельным классом, который стал соавтором исходного класса. Его поведение станет понятным благодаря собственным модульным тестам.

Затем я могу посмеяться над его поведением при попытке проверить исходный класс, чтобы затем сосредоточиться на проверке поведения открытого интерфейса этого класса, а не на проверке комбинаторного взрыва открытого интерфейса и поведения всех его закрытых методов. ,

Я вижу это аналогично вождению автомобиля. Когда я веду машину, я не еду с поднятым капотом, поэтому я вижу, что двигатель работает. Я полагаюсь на интерфейс, который обеспечивает автомобиль, а именно на счетчик оборотов и спидометр, чтобы знать, что двигатель работает. Я полагаюсь на то, что машина действительно движется, когда я нажимаю педаль газа. Если я хочу проверить двигатель, я могу проверить его изолированно. : D

Конечно, непосредственное тестирование частных методов может быть последним средством, если у вас есть унаследованное приложение, но я бы предпочел, чтобы унаследованный код был реорганизован для обеспечения лучшего тестирования. Майкл Фезерс написал прекрасную книгу на эту тему. http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052

Частные типы, внутренние и частные члены таковы по какой-то причине, и часто вы не хотите связываться с ними напрямую. И если вы это сделаете, есть вероятность, что вы сломаетесь позже, потому что нет никакой гарантии, что парни, создавшие эти сборки, сохранят частные / внутренние реализации как таковые.

Но иногда, когда я выполнял некоторые хаки / исследования скомпилированных или сторонних сборок, я сам заканчивал тем, что хотел инициализировать частный класс или класс с закрытым или внутренним конструктором. Или иногда, когда я имею дело с предварительно скомпилированными устаревшими библиотеками, которые я не могу изменить - я заканчиваю тем, что пишу несколько тестов для частного метода.

Так родился AccessPrivateWrapper - http://amazedsaint.blogspot.com/2010/05/accessprivatewrapper-c-40-dynamic.html - это быстрый класс-обертка, который облегчит работу с помощью динамических функций и отражения C # 4.0.

Вы можете создавать внутренние / частные типы, такие как

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

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

Ну, вы можете тестировать приватный метод двумя способами

1. Вы можете создать экземпляр PrivateObjectкласса, синтаксис которого выглядит следующим образом

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

2. Вы можете использовать отражение.

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

Я также использовал метод InternalsVisibleToAttribute. Стоит также упомянуть, что, если вы чувствуете себя некомфортно, когда делаете свои ранее частные методы внутренними, чтобы достичь этого, то, возможно, они все равно не должны быть предметом прямых модульных тестов.

В конце концов, вы тестируете поведение своего класса, а не его конкретную реализацию - вы можете изменить последний, не изменяя первый, и ваши тесты все равно должны пройти.

Есть 2 типа частных методов. Статические приватные методы и нестатические приватные методы (методы экземпляра). Следующие 2 статьи объясняют, как выполнить модульное тестирование частных методов с примерами.

1. Модульное тестирование статических частных методов
2. Модульное тестирование нестатических частных методов

MS Test имеет хорошую встроенную функцию, которая делает приватные члены и методы доступными в проекте, создав файл с именем 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();
        }
    }

С классами, производными от BaseAccessor

такие как

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

На CodeProject есть статья, в которой кратко обсуждаются плюсы и минусы тестирования частных методов. Затем он предоставляет некоторый код отражения для доступа к закрытым методам (аналогично коду, представленному Маркусом выше). Единственная проблема, которую я обнаружил в примере, заключается в том, что код не учитывает перегруженные методы.

Вы можете найти статью здесь:

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

Объявите их internal, а затем используйте, InternalsVisibleToAttributeчтобы разрешить их сборке тестового модуля.

Я склонен не использовать директивы компилятора, потому что они быстро загромождают вещи. Один из способов смягчить это, если они вам действительно нужны, - поместить их в частичный класс и заставить вашу сборку игнорировать этот файл .cs при создании рабочей версии.

Вы не должны в первую очередь тестировать закрытые методы вашего кода. Вы должны тестировать «открытый интерфейс» или API, общедоступные вещи ваших классов. API - это все открытые методы, которые вы предоставляете внешним абонентам.

Причина в том, что, как только вы начинаете тестировать закрытые методы и внутренние компоненты вашего класса, вы связываете реализацию вашего класса (личные вещи) с вашими тестами. Это означает, что когда вы решите изменить детали реализации, вам также придется изменить свои тесты.

По этой причине вам следует избегать использования InternalsVisibleToAtrribute.

Вот большой доклад Иана Купера, который освещает эту тему: Ian Cooper: TDD, где все пошло не так

Иногда бывает полезно протестировать частные объявления. По сути, компилятор имеет только один открытый метод: Compile (string outputFileName, params string [] sourceSFileNames). Я уверен, что вы понимаете, что было бы сложно протестировать такой метод без проверки каждого «скрытого» объявления!

Вот почему мы создали Visual T #: чтобы облегчить тестирование. Это бесплатный язык программирования .NET (совместимый с C # v2.0).

Мы добавили оператор «.-». Это просто ведет себя как "." оператор, за исключением того, что вы также можете получить доступ к любой скрытой декларации из ваших тестов, не меняя ничего в вашем тестируемом проекте.

Взгляните на наш веб-сайт: загрузите его бесплатно .

Я удивлен, что никто еще не сказал этого, но решение, которое я использовал, состоит в том, чтобы создать статический метод внутри класса, чтобы проверить себя. Это дает вам доступ ко всему общему и частному для тестирования.

Кроме того, на языке сценариев (с возможностями OO, такими как Python, Ruby и PHP), вы можете сами выполнить проверку файла при запуске. Хороший быстрый способ убедиться, что ваши изменения ничего не сломали. Это, очевидно, делает масштабируемое решение для тестирования всех ваших классов: просто запустите их все. (Вы также можете сделать это на других языках с помощью void main, которая также всегда выполняет свои тесты).

Я хочу создать четкий пример кода, который вы можете использовать в любом классе, в котором вы хотите протестировать закрытый метод.

В вашем тестовом классе просто включите эти методы, а затем используйте их, как указано.

  /**
   *
   * @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', массив (param1, param2, param3));

Просто выдайте параметры в том порядке, в котором они отображаются в оригинальной закрытой функции.

Для тех, кто хочет запускать приватные методы без всякой путаницы. Это работает с любой структурой модульного тестирования, использующей только старый добрый Reflection.

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

Затем в ваших реальных тестах вы можете сделать что-то вроде этого:

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

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

MbUnit получил хорошую обертку для этого под названием Reflector.

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

Вы также можете установить и получить значения из свойств

dogReflector.GetProperty("Age");

Относительно "частного теста" я согласен, что .. в идеальном мире. нет смысла делать частные юнит-тесты. Но в реальности вы можете захотеть написать приватные тесты вместо рефакторинга кода.

Вот хорошая статья о модульном тестировании частных методов. Но я не уверен, что лучше сделать приложение специально разработанным для тестирования (это все равно, что создавать тесты только для тестирования) или использовать рефлексию для тестирования. Уверен, большинство из нас выберет второй путь.

На мой взгляд, вам следует только протестировать открытый API вашего classe.

Обнародование метода для его модульного тестирования нарушает инкапсуляцию, раскрывая детали реализации.

Хороший публичный API решает непосредственную задачу клиентского кода и полностью решает эту задачу.

Я использую класс PrivateObject . Но, как упоминалось ранее, лучше избегать тестирования частных методов.

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

CC -Dprivate=public

«CC» - это компилятор командной строки в системе, которую я использую. -Dfoo=barделает эквивалент #define foo bar. Таким образом, эта опция компиляции эффективно меняет все личные вещи на публичные.

Вот пример, сначала подпись метода:

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

Вот тест:

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

Чтобы сделать это, нужно иметь свой метод protectedи написать тестовое устройство, которое наследует ваш класс для тестирования. Таким образом, вы не поворачиваете свой метод public, но включаете тестирование.

1) Если у вас есть унаследованный код, то единственный способ проверить приватные методы - это рефлексия.

2) Если это новый код, то у вас есть следующие варианты:

• Используйте отражение (для сложных)
• Написать модульный тест в том же классе (делает рабочий код уродливым, если в нем также есть тестовый код)
• Рефакторинг и сделать метод общедоступным в некотором классе утилит
• Используйте аннотацию @VisibleForTesting и удалите приватную

Я предпочитаю метод аннотации, самый простой и наименее сложный. Единственная проблема заключается в том, что мы увеличили видимость, что, я думаю, не является большой проблемой. Мы всегда должны кодировать интерфейс, поэтому, если у нас есть интерфейс MyService и реализация MyServiceImpl, то у нас могут быть соответствующие тестовые классы MyServiceTest (методы интерфейса тестирования) и MyServiceImplTest (тестировать частные методы). В любом случае все клиенты должны использовать интерфейс таким образом, что хотя видимость приватного метода была увеличена, это не должно иметь большого значения.

Вы также можете объявить его как открытый или внутренний (с InternalsVisibleToAttribute) при сборке в режиме отладки:

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

Он раздувает код, но будет privateв сборке релиза.

Вы можете сгенерировать тестовый метод для частного метода из Visual Studio 2008. Когда вы создаете модульный тест для частного метода, папка «Ссылки на тест» добавляется в ваш тестовый проект, а средство доступа добавляется в эту папку. Метод доступа также упоминается в логике метода модульного тестирования. Этот метод доступа позволяет вашему модульному тесту вызывать закрытые методы в тестируемом коде. Для подробностей взгляните на

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

Также обратите внимание, что InternalsVisibleToAtrribute имеет требование, чтобы ваша сборка имела строгое имя , что создает свой собственный набор проблем, если вы работаете в решении, для которого раньше этого требования не было. Я использую аксессор для тестирования приватных методов. Посмотрите этот вопрос, что в качестве примера этого.