Интеграция обуви и системные тесты в инфраструктуру модульных тестов - PullRequest
3 голосов
/ 19 июня 2010

Как показано в статье менеджера домена , меня интересует создание интеграционного тестового жгута, который создает сервер и множество клиентов, где все они работают в одном процессе .Но как только я достигну этой цели, у меня возникнет искушение выполнить такие интеграционные и системные тесты в рамках модульного тестирования (тест NUnit или VS Team).

Каковы плюсы и минусы выбора запуска интеграции или системных тестов в рамках модульного тестирования?Вот мой собственный удар:

Плюсы

  • Это может сократить время и стоимость проведения интеграционных тестов.
  • Интеграционные тесты выполняются, возможно, с каждой сборкой.

Минусы

  • Не все интеграционные тесты будут быстрыми.Для запуска некоторых из них требуется минута (например, интеграционное тестирование, ориентированное на производительность).

В любом случае, если мой новый код интеграционного тестирования - , а не , помещенный в модульрамки тестирования, где бы вы порекомендовали его разместить?Иными словами, какие фреймворки для "тестирования интеграции" вы бы порекомендовали?

Ответы [ 3 ]

3 голосов
/ 19 июня 2010

Я не думаю, что что-то не так с написанием ваших интеграционных тестов с использованием Unit Testing Framework, с которым вы уже знакомы.Поскольку это интеграционные тесты, есть несколько вещей, которые отличают их от ваших модульных тестов.Одним из них является тот факт, что они зависят от внешних систем (даже если вы добавляете некоторые из них в свой код), поэтому, если одна из них недоступна, ваши тесты не пройдут.Другой, как вы уже указали, заключается в том, что интеграционные тесты выполняются дольше.

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

В зависимости от используемой среды тестирования существуют разные способы отделения модульных тестов от интеграционных тестов, так что вы можете настроить свои сборки на выполнение одного или обоих.Один из способов - переместить интеграционные тесты в отдельный проект и выполнять тесты в этом проекте только во время вашей ночной сборки.Другой - использовать атрибут типа в NUnit , чтобы пометить некоторые тесты как интеграционные.Затем вы можете настроить тестировщика так, чтобы он исключал тесты из этой категории для сборок, которые вы не хотите выполнять интеграционными тестами.

0 голосов
/ 04 октября 2016

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

По этой причине я бы сказал, что вполне разумно использовать инфраструктуру «модульного» тестирования для неуниверсального тестирования.

Плюсы

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

Минусы

  • Нет помощи при выполнении задач высокого уровня, таких как запуск или мониторинг процесса, установка или настройка базы данных частотребуется для не модульных тестов.
  • Поскольку они используют язык программирования общего назначения, тесты могут стать многословными из-за сложности их настройки.в частности, системные тесты
  • Большинство структур модульных тестов не предоставляют никаких инструментов высокого уровня, таких как запись / воспроизведение планов тестирования, или интерфейсы, подходящие для приемочного тестирования / бизнес-пользователей.
  • Настройка / разборкаможет быть уродливым и сложным, если в тесте участвует много процессов / систем.Многие рамки модульных тестов не поддерживают совместную отмену, которая позволила бы вам убрать дом.
0 голосов
/ 09 мая 2012

точка автоматического тестирования предназначена для помощи вашего теста.

Вы потратили время на запись теста.Хорошо, что в будущем его можно будет запустить снова (это поможет убедиться, что вы ничего не сломали).

NUnit - это система, которая поможет вам выполнить те тесты, которые you хочу бежать.Вы не плохой человек для того, чтобы «более тщательные тесты» смешивались с «надуманными тестами».

Единственным недостатком является то, что некоторые из этих тестов занимают слишком много времени;и разработчик не должен запускать тесты при каждом запуске.Вот тогда вполне допустимо категоризировать (то есть выборочно и временно) отключить тесты.


У меня есть написанные модульные тесты, специально предназначенные для документирования ошибки в функции.Нет необходимости в исправлении это , так как вероятность того, что кто-нибудь получит ошибку ( меня даже оскорбили за то, что я даже протестировал дело), ​​равна одному на миллион.1025 *.Но, по крайней мере, тест есть - напоминая всем навсегда о том, что функция не идеальна:

void TestDateToString_KnownBug_FailsOnPseudo();

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

...