Существует ли условный оператор типа "#if DEBUG", который можно использовать в VS 2008 для определения того, запускается ли код из модульного теста? (Мы используем встроенное модульное тестирование MS.)
Например:
#if !UNITTEST
// Do some GUI stuff we don't want to see when unit testing
#endif
Согласовано. Избегайте (по возможности) кодирования всего, что при тестировании будет реагировать иначе, чем в дикой природе.
Спасибо. Изначально я планировал использовать этот подход, но меня уговорили изучить этот путь на случай, если он существует ...





Обратите внимание, что любое такое определение имеет смысл только во время компиляции. Следовательно, вам придется скомпилировать его одним способом, чтобы получить код, и другим способом, чтобы этот код был удален. Итак, ваш код будет «ощущать», что он выполняется фреймворком модульного тестирования. Вам понадобятся две отдельные сборки. Если это действительно то, что вы хотите, определить символ достаточно просто. Просто перейдите в «Свойства проекта», вкладку «Сборка» и добавьте «ЕДИНИЧНЫЙ ТЕСТ» под условными символами компиляции.
Я согласен с комментариями, в которых говорится, что нужно избегать этого в целом, но я сам делал это в прошлом. IIRC, он использовался для переключения между «базой данных модульных тестов» (т. Е. Одноразовой) и «тестовой базой данных с полезными данными», которая была случайно стерта модульными тестами слишком много раз ...
Наше решение заключалось в том, чтобы иметь класс UnitTestDetector (или что-то в этом роде), у которого было единственное статическое свойство «InUnitTest». Это будет определяться тем, был ли NUnit загружен в текущий домен приложения (опять же, IIRC). После первого зондирования результат будет кэшироваться, чтобы предотвратить снижение производительности.
Условный оператор, о котором вы говорите, недоступен, потому что это директива компилятора; У вас должна быть тестовая сборка, которую вы могли бы определить своей собственной директивой компилятора TEST. Однако, как отметили комментаторы, вы не должны запускать другой код для теста, чем в производственной среде, это противоречит цели.
Спасибо. Я планировал использовать отказ от использования кода, специфичного для модульных тестов, но меня уговорили изучить этот путь на случай, если он существует. Теперь я этого не сделаю! :)
+1 за ответ Криса. Похоже, это хорошее место для класса типа "Test Fake" или "Test Double". Можете ли вы извлечь элементы графического интерфейса, которые вы хотите скрыть, в виртуальные или абстрактные методы, а затем создать (в своем тестовом проекте) класс, производный от тестируемого класса и переопределяющий код графического интерфейса?
Изменение поведения вашего программного обеспечения специально для тестирования сводит на нет тестирование, потому что вы больше не тестируете то, что вы поставляете. Вы уверены, что это правильный подход к проблеме, которую вы пытаетесь решить? В чем причина такого особого поведения во время теста?