Модульное тестирование - лучшая практика - PullRequest
Новая
       27

Модульное тестирование - лучшая практика

5 голосов
/ 21 июля 2011

Я использую Visual Studio 2010 Professional с платформой MSTest для выполнения модульных тестов.У меня есть неприятный производственный код для тестирования.Первая проблема заключается в том, что проблемный код находится в конструкторе.Я покажу пример: 

class ClassToTest
    {
        public SomeEnum UpperBorder;
        public SomeEnum LowerBorder;
        public int var1;
        private readonly SomeEnum2 _ethnicGroup;
        private readonly double _age;
        public int DataStart;
        public int DataEnd;
        public double[] DarkRedDarkYellow;
        public double[] DarkYellowGreen;
        public double[] GreenLightYellow;
        public double[] LightYellowLightRed;

        public ClassToTest(SomeEnum upperBorder, SomeEnum lowerBorder, int var1, SomeEnum2 ethnicGroup, int age)
        {
            UpperBorder = upperBorder;
            LowerBorder = lowerBorder;
            BscanIndex = bscanIndex;
            _ethnicGroup = ethnicGroup;
            _age = age;
            DataStart = 0;
            DataEnd = 0;
            DarkRedDarkYellow = null;
            DarkYellowGreen = null;
            GreenLightYellow = null;
            LightYellowLightRed = null;
        }
}

Мой вопрос:

  • написать один тест с утверждением assert для каждой переменной?или напишите пару тестов и в каждом тесте проверяйте сразу только одну переменную?например: 

[TestMethod()]
public void ClassToTest_Constructor_upperBorder_PTest()
{
    //ACT
    var ob = new ClassToTest(SomeEnum.bor1, SomeEnum.bor2,10,SomeEnum2.Asian,10);
    //ASSERT
    Assert.IsNotNull(object);
    Assert.AreEqual(ob.upperBorder,SomeEnum.bor1);
}
  • Должен ли я проверить, правильно ли конструктор присваивает параметры частному полю?Или, если будет свойство, которое возвращает это приватное поле, но оно выполняет какое-то другое действие, такое как событие триггера, действие журнала и т. Д.

Я не могу найти информацию об этом.Так что ваш совет будет самым ценным.

Ответы [ 4 ]

6 голосов
/ 21 июля 2011

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

Частные поля обычно не проверяются юнит-тестами.Модульный тест должен предпочтительно проверять внешне видимое поведение и состояние.

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

4 голосов
/ 21 июля 2011

Напишите один тест с утверждением assert для каждой переменной и получите мой голос:

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

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

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

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

Ознакомьтесь с этой статьей, чтобы узнать, как это легко сделать.

0 голосов
/ 26 мая 2016

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

  1. Отдельный проект для модульного тестирования.
  2. Один класс для написания модульных тестов функций водин класс основного кода.
  3. Условия покрытия внутри функций
  4. Разработка через тестирование (TDD)

Если вы действительно хотите узнать больше (с примерами), сделайтевзгляните на этот урок

Модульные тесты c # - лучшие практики https://www.youtube.com/watch?v=grf4L3AKSrs

0 голосов
/ 20 апреля 2015

Лучшее решение, которое я нашел для таких проблем, состоит в следующем:

  1. Переместите код конструктора в защищенный метод инициализатора, который вызывается из конструктора.Сохраните ваш конструктор с теми же параметрами и не создавайте конструктор по умолчанию (без параметров).
  2. Для теста создайте унаследованную тестируемую версию, которая должна иметь следующее:
    • aконструктор по умолчанию, который ничего не делает (даже не вызывает инициализатор)
    • открытая перегрузка защищенного инициализатора
    • открытые открытые свойства любых частных / защищенных значений, которые вы хотите проверить

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

...