Лучшая практика модульного тестирования для решений Visual Studio

Question

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

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

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

Спасибо.

Answer 1

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

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

Лично я бы все равно просто все построил ...

Answer 2

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

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

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