Куда мне положить мои издевательства? - PullRequest
7 голосов
/ 30 июля 2010

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

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

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

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

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

У кого-нибудь есть мысли по поводу того, где следует размещать классы-макеты?

спасибо за любую помощь T

Ответы [ 3 ]

11 голосов
/ 30 июля 2010

Ваши макеты должны идти в ваших проектах модульных тестов. Ваше приложение не должно зависеть от ваших фиктивных объектов. Обычно ваше приложение будет использовать интерфейсы, а ваши mocks будут реализовывать эти интерфейсы. Ваша заявка не должна или должна ссылаться на ваш тестовый проект.

2 голосов
/ 26 марта 2018

Моки должны храниться в отдельном проекте . Всего у нас 3 варианта

  1. Макеты в модульном тестовом проекте

    Не будет работать, если проект пользовательского интерфейса должен использовать это для запуска (например, фиктивная служба / тест частичной интеграции / тест дыма). Даже если на тестовый проект есть ссылка в файле конфигурации посредством внедрения зависимостей, мы не хотим переносить dll модульного тестирования в другие среды. Сегодня больше внимания уделяется интеграционным тестам, поскольку Модульные тесты менее продуктивны , что, конечно, выходит за рамки этой темы, но мы должны понимать, что макеты - это не только модульные тесты.

  2. Проверяет в проектах самого приложения (служба-вставляет в сервис-проект)

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

  3. Макет в отдельном проекте .

    Здесь могут ссылаться как проекты модульных тестов, так и другие проекты запуска. Интеграционные тесты с использованием внешнего интерфейса имеют дополнительную возможность макетировать определенную область (например, внешние API). Или покурите пользовательский интерфейс с помощью макетов (в то время как другие команды развертывают сервер). Короче говоря, у нас есть много вариантов использования макета. Не привязан к юнит-тестированию в одиночку. Но самое важное преимущество заключается в том, что когда мы хотим быть уверенными в том, что он будет запущен, мы можем удалить фиктивный проект (или dll) из развертывания. Таким образом, если какой-либо проект или файл конфигурации случайно ссылаются на макет, мы получаем ошибку времени выполнения . Что помогает пресечь это в зародыше.

0 голосов
/ 25 марта 2011

То, что мы делаем в наших проектах, - это определение внутренних и внешних зависимостей.Макеты для внутренних зависимостей входят в проект модульного тестирования (или в отдельный проект Mocks, если они используются в решении).Макеты для внешних зависимостей попадают в само приложение, а затем используются для тестирования развертывания и интеграции.

Внешняя зависимость - это то, что является экологическим - так, Active Directory, веб-служба, база данных, регистратор, Что-то в этом роде.Внедрение зависимостей выполняется аналогичным образом - внешние зависимости определяются в файле конфигурации, поэтому мы можем легко выбирать, что мы хотим использовать во время выполнения.

Внутренняя зависимость - это почти все остальное.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...