Тестирование работы внутренних функций с использованием nunit тестов

Question

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

Проверяются только значения методов GetValues(). Как я могу проверить работу других методов внутри GetValues(). Как я могу проверить его работу с помощью модульного тестирования?

[TestFixture]
    public class Class1
    {
        [Test]
        public void Tester()
        {
            TesterClass clasObj;
            int a = clasObj.GetValues();
            Assert.AreEqual(10,a);
        }
    }

Answer 1

Как я могу проверить его работу с помощью модульного тестирования?

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

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

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

Иногда вы хотите протестировать внутреннее устройство, и один из способов - использовать InternalsVisibleToAttribute и пометить тестовую сборку как «друга».

http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute.aspx

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

Answer 2

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

Поэтому разделите GetValues ​​на новый объект, который вы можете проверить, например:

ExampleFormatter.FormatValues()

Теперь это будет публичный класс с публичным методом, что означает, что вы можете легко его протестировать. Все, что GetValues должен сделать сейчас, это вызвать FormatValues с правильными параметрами. Вы можете использовать фиктивный объект , чтобы убедиться, что это происходит так, как ожидалось. Так как это теперь публично, когда можно тестировать такие вещи, как форматирование значений, как мы ожидаем и так далее. Каждый раз, когда вам трудно протестировать какой-либо код, это обычно означает, что код делает слишком много, сломайте его!

Answer 3

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