Специальный флаг компилятора для запуска модульного теста

Question

У меня есть вопрос, касающийся визуальных студий, встроенных в набор тестов. VS studio выполняет эти тесты с применением некоторых специальных флагов компилятора?

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

Поэтому я хотел бы реализовать некоторые сообщения, только если приложение работает в тестовом режиме.

Спасибо за любой ответ! Andreas

Answer 1

VS компилирует / строит проекты с выбранной конфигурацией сборки.Таким образом, решение может состоять в том, чтобы создать отдельную конфигурацию сборки самостоятельно, а затем использовать константу (например, TEST) для проектов в этой конкретной конфигурации сборки.Выполнение метода вывода может быть ограничено либо директивой #if TEST, либо атрибутом [Conditional("TEST")].Вы можете настроить свой сервер сборки, чтобы всегда запускать тесты с этой конкретной конфигурацией сборки, чтобы вы могли видеть дополнительные выходные данные.Однако при запуске тестов с VS

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

Answer 2

Создайте новую конфигурацию решения «Тест» (если у вас ее еще нет) и переключитесь на нее.Откройте настройки проекта, перейдите на вкладку «Сборка» и определите новый символ TEST.Нажмите OK.

Измените реализацию Equals на

public override bool Equals (object obj)
{
    #if TEST
     // Your implementation
    #else
      return base.Equals (obj);
    #endif
}

. Это скомпилирует тело другого метода для вашей тестовой конфигурации.

Answer 3

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

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

Вместо этого вы должны написать свой тест таким образом, чтобы только одна единственная вещь могла быть неправильной.Таким образом, если тест не пройден, вы уже знаете, что не так.Итак, если вы тестируете метод equals, который учитывает 2 свойства, напишите набор небольших тестов, которые проверяют, что происходит во всех возможных комбинациях этих двух свойств, и проверяют результат метода Equals.

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

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

public static class TestExtensions
{
  public static void ShouldEqual( this YourType subject, YourType other )
  {
     // Check parameters for null here if needed
     if( !subject.Equals( other ) )
     {
       // custom logging here
       Assert.Fail("Objects are not equal"); // test fails
     }
  }
}

Answer 4

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

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

Тогда во время выполнения вы можете выбрать стратегию для метода Equals через Dependency Injection или, может быть, простую функцию, подобную этой, в вашем базовом классе:

public override bool Equals (object obj)
{
    if ( EqualsStrategy != null)
    {
        return EqualsStrategy.Equals(this,object);
    }
    else
    {
       return base.Equals(obj);
    }
}

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