Рекомендации по тестированию модулей для Visual Studio Solutions

Question

Привет всем, мне поручено перестроить процесс сборки на этой стадии работы, и я хотел бы начать включать модульное тестирование (nUnit) в наши проекты. Благодаря моим исследованиям я хорошо разбираюсь в технологии, которую буду использовать, но я хотел бы получить некоторые рекомендации по лучшим методам настройки моего решения для тестирования и убедиться, что мое предлагаемое решение является обоснованным.

Наше основное решение VS 2008 имеет около 4 проектов. Для каждого проекта я собираюсь создать соответствующий проект тестового модуля и добавить его в наше решение. Я бы хотел, чтобы наши разработчики начали разрабатывать это решение, и весь проверенный код вернется к магистрали (используя SVN). Для нашего процесса сборки я буду использовать сервер непрерывной интеграции для сборки и тестирования кода разработки в багажнике (с модульными тестами). Пока это здание, я хочу иметь решение для развертывания, в котором есть мои 4 проекта и (но нет модульных тестов), и нажимать этот код для QA, например Test | Затем постановка производится в конечном итоге. Когда я нажимаю код для каждой среды, моя цель состоит в том, чтобы не иметь проектов тестирования модулей, которые были нажаты с этим кодом.

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

Спасибо.

Answer 1

Почему у вас есть два разных решения? Просто используйте одно решение, которое включает в себя модульные тесты, а затем выберите только выходные данные производственных проектов для отправки в QA/Test. (Или, если QA/Test получают полный исходный код, пусть их все еще строят единичные тестовые проекты и просто игнорируют их.) Наличие нескольких решений звучит как дополнительное усилие без усиления.

В качестве альтернативы, если вы действительно хотите построить без единичных тестов, у вас может быть одна конфигурация решения (например, отладка и выпуск), которая просто не создает единичные тестовые проекты. В меню, где вы обычно выбираете Debug или Release, выберите «Configuration Manager ...», а затем в следующем диалоговом окне выберите раскрывающийся список «Конфигурация активного решения» и выберите «< Новый>», чтобы создать новый , Выберите подходящую конфигурацию для копирования (возможно, Release), а затем просто отключите проекты тестирования модулей.

Лично я до сих пор просто построить все, хотя ...

Answer 2

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

Однако отдельные проекты тестирования модулей практически необходимы, если необходимо учитывать межсистемные зависимости. Разделение тестов (интеграция, а не единиц измерения) дает свободу настройки среды выполнения теста и позволяет избежать появления нежелательных фрагментов кода в основную базу кода. С другой стороны, вам нужно будет использовать [assembly:InternalsVisibleTo("test_assembly_name")] для включения тестового кода для доступа к внутренним членам.

Условная компиляция может использоваться для исключения тестового кода из сборников релизов. Хотя в некоторых специальных сценариях может оказаться полезным включить единый тестовый код даже в сборку выпуска и позволить приложению выполнять самотестирование. Пример: интерфейс объявлен с семантическим контрактом, который разработчик должен предоставить конкретным атрибутам методам/свойствам/классу, реализующему интерфейс.В случае, если приложение может загружать некоторые дополнительные модули (сборки, неизвестные во время компиляции), возможность самотестирования может помочь обеспечить работу всей системы.