Могу ли я использовать инструменты модульного тестирования для интеграционного тестирования?

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

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

Мне остается задаться вопросом, могу ли я по-прежнему писать модульные тесты (используя Visual Studio) для тестирования этого компонента или это противоречит лучшим практикам? Из моего чтения кажется, что инструменты модульного тестирования в Visual Studio в значительной степени предназначены именно для этого - методов модульного тестирования и свойств компонента.

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


visual-studio-2010 unit-testing integration-testing testing
person scubasteve    schedule 15.01.2014    source источник
comment
Вам следует посмотреть выступление Колина Бауэрна на странице Создание лучших интеграционных тестов на Канале 9.   -  person kagundajm    schedule 16.01.2014

Ответы (2)


arrow_upward
0
arrow_downward

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

  2. В будущем вам следует поместить этот сторонний компонент за интерфейс, от которого зависят другие компоненты вашей системы. Затем эти другие части можно протестировать отдельно от стороннего компонента.

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

person verdammelt    schedule 16.01.2014

arrow_upward
0
arrow_downward

Тестирование стороннего компонента так, как вы это делаете, безусловно, не противоречит передовой практике.

Однако такой тест будет классифицироваться как тест (под)системы, поскольку а) сторонний компонент тестируется как изолированная (под)система, и б) ваша цель тестирования — проверить поведение API. уровне, а не на тестировании аспектов реализации более низкого уровня.

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

Тем не менее, я хотел бы сделать два замечания:

  • Тот факт, что тест не является юнит-тестом, не делает его менее ценным. Я сталкивался с ситуациями, когда я говорил людям, что их тесты не являются юнит-тестами, и они злились на меня, потому что думали, что я хочу сказать им, что их тесты не имеют смысла — досадное недоразумение.
  • К какой категории относится тест, не определяется техническими особенностями, такими как используемая среда тестирования. Это скорее определяется целями, которых вы хотите достичь с помощью теста, например, какие типы ошибок вы хотите найти.
person Dirk Herrmann    schedule 05.10.2017