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

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

Итак, NUnit не предоставляет никакого механизма для тестирования непубличных членов.

Основная цель модульного тестирования - проверить общедоступные методы класса. Эти общедоступные методы будут использовать эти частные методы. Модульное тестирование проверяет поведение общедоступных материалов.

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

Вы просто не должны тестировать ничего, что не является общедоступным.

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

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

Обычно при написании модульных тестов тестируются только общедоступные методы.

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

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

Возможно, будет правильным переместить их во вспомогательный класс и сделать их там общедоступными. Этот класс не может быть предоставлен вашим API.

Таким образом, тестовый код никогда не смешивается с вашим общедоступным кодом.

Аналогичная проблема заключается в тестировании частных классов, т.е. классы, которые вы не экспортируете из сборки. В этом случае вы можете явно сделать вашу сборку тестового кода другом сборки производственного кода, используя атрибут InternalsVisibleTo.

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

Так что это действительно сводится к тому, заботитесь ли вы больше о правильном коде или сокрытии информации. Я бы сказал, что видимость пакета - хороший компромисс, поскольку для доступа к этому методу кому-то нужно будет поместить свой класс в ваш пакет. Это действительно должно заставить их дважды подумать, действительно ли это разумно.

Я, кстати, парень, занимающийся Java, так что package visiblilty можно было бы назвать чем-то совершенно другим в C#. Достаточно сказать, что это когда два класса должны находиться в одном пространстве имен, чтобы получить доступ к этим методам.

Можно протестировать частные методы, объявив вашу тестовую сборку как дружественную сборку целевой сборки, которую вы тестируете. См. Ссылку ниже для получения подробной информации:

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

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

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

Если вы все еще чувствуете потребность в тестировании внутреннего, вы также можете подумать о насмешках в своем тестировании, поскольку вы, вероятно, захотите сосредоточиться на одном фрагменте кода. Мокинг - это когда вы вводите в него зависимости объектов, но внедряемые объекты не являются «реальными» или производственными объектами. Это фиктивные объекты с жестко запрограммированным поведением, облегчающим выявление поведенческих ошибок. Rhino.Mocks - популярный бесплатный фреймворк для создания макетов, который по сути напишет объекты за вас. TypeMock.NET (коммерческий продукт с доступной версией сообщества) - это более мощный фреймворк, который может имитировать объекты CLR. Очень полезно для имитации классов SqlConnection / SqlCommand и Datatable, например, при тестировании приложения базы данных.

Надеюсь, этот ответ даст вам немного больше информации о модульном тестировании в целом и поможет вам получить лучшие результаты от модульного тестирования.

Приносим извинения, если это не отвечает на вопрос, но такие решения, как использование отражения, операторов #if #endif или отображение частных методов, не решают проблему. Может быть несколько причин не делать частные методы видимыми ... что, если это производственный код, и команда, например, ретроспективно пишет модульные тесты.

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

Хотя я согласен с тем, что основное внимание при модульном тестировании должно уделяться общедоступному интерфейсу, вы получите гораздо более детальное представление о своем коде, если также протестируете частные методы. Платформа тестирования MS позволяет это за счет использования PrivateObject и PrivateType, а NUnit - нет. Вместо этого я делаю следующее:

private MethodInfo GetMethod(string methodName)
{
    if (string.IsNullOrWhiteSpace(methodName))
        Assert.Fail("methodName cannot be null or whitespace");

    var method = this.objectUnderTest.GetType()
        .GetMethod(methodName, BindingFlags.NonPublic | BindingFlags.Instance);

    if (method == null)
        Assert.Fail(string.Format("{0} method not found", methodName));

    return method;
}

Это означает, что вам не нужно идти на компромисс с инкапсуляцией в пользу тестируемости. Имейте в виду, что вам нужно изменить свой BindingFlags, если вы хотите протестировать частные статические методы. Приведенный выше пример относится только к методам экземпляра.

Я за возможность тестировать частные методы. Когда xUnit запускался, он предназначался для тестирования функциональности после написания кода. Для этого достаточно протестировать интерфейс.

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

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

По сути, у меня есть все классы модульного тестирования в сборке, которую они тестируют, в пространстве имен UnitTest ниже значения по умолчанию для этой сборки - каждый тестовый файл заключен в:

#if DEBUG

...test code...

#endif

block, и все это означает, что а) он не распространяется в выпуске и б) я могу использовать объявления уровня internal / Friend без прыжков через кольцо.

Еще одна вещь, которую это предлагает, более подходящая для этого вопроса, - это использование классов partial, которые можно использовать для создания прокси для тестирования частных методов, например, для тестирования чего-то вроде частного метода, который возвращает целочисленное значение:

public partial class TheClassBeingTested
{
    private int TheMethodToBeTested() { return -1; }
}

в основных классах сборки и в тестовом классе:

#if DEBUG

using NUnit.Framework;

public partial class TheClassBeingTested
{
    internal int NUnit_TheMethodToBeTested()
    {
        return TheMethodToBeTested();
    }
}

[TestFixture]
public class ClassTests
{
    [Test]
    public void TestMethod()
    {
        var tc = new TheClassBeingTested();
        Assert.That(tc.NUnit_TheMethodToBeTested(), Is.EqualTo(-1));
    }
}

#endif

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

Вы можете сделать свои методы защищенными внутренними, а затем использовать assembly: InternalsVisibleTo("NAMESPACE") в ваше тестовое пространство имен.

Следовательно, НЕТ! Вы не можете получить доступ к частным методам, но это обходной путь.

По теории модульного тестирования тестировать следует только контракт. т.е. только публичные члены класса. Но на практике разработчик обычно хочет протестировать и внутренних участников - и это неплохо. Да, это противоречит теории, но на практике иногда может быть полезно.

Итак, если вы действительно хотите протестировать внутренних членов, вы можете использовать один из следующих подходов:

1. Сделайте своего участника общедоступным. Во многих книгах авторы предлагают это подход как простой
2. Вы можете сделать себя участниками внутренних и добавить InternalVisibleTo в сборка
3. Вы можете сделать членов класса защищенными и унаследовать свой тестовый класс из вашего тестируемого класса.

Пример кода (псевдокод):

public class SomeClass
{
    protected int SomeMethod() {}
}
[TestFixture]
public class TestClass : SomeClass{
    
    protected void SomeMethod2() {}
    [Test]
    public void SomeMethodTest() { SomeMethod2(); }
}

Если вам нужно получить доступ к нестатическому частному методу класса, попробуйте следующее:

class Foo 
{
    private int Sum(int num1, int num2)
    {
        return num1 + num2;
    }
}

MethodInfo sumPrivate = 
    typeof(Foo).GetMethod("Sum", BindingFlags.NonPublic | BindingFlags.Instance);

int sum = (int)sumPrivate.Invoke(new Foo(), new object[] { 2, 5 });
// 7