Как изолировать модульные тесты - PullRequest
1 голос
/ 22 сентября 2011

У нас есть проект пакетной обработки, который использует кэш (который опирается на статические данные). К сожалению, модульные тесты для этого проекта путают другие модульные тесты в том же решении (из-за статических данных), поэтому мне нужно изолировать тесты пакетной обработки от всех других модульных тестов. Фреймворк / организация, в которой мы работаем, очень строгие, и все юнит-тесты должны быть в одном проекте. Все же все модульные тесты должны быть запущены в сборке. Мне нужно убедиться, что тестовые модули пакетной обработки не выполняются в том же процессе, что и другие модульные тесты. Есть ли способ сделать это?

Edit: В частности, я ищу способ контролировать, какой процесс выполняется каждый тест. Я не смог найти документацию по этому вопросу, но похоже, что все модульные тесты выполняются под одним и тем же экземпляром процесса QTAgent32.exe. Существует параметр, определяющий, выполняются ли тесты в одном и том же процессе (Инструменты> Параметры> Инструменты тестирования> Выполнение теста> Поддерживать работу тестового двигателя между тестами). Тем не менее, это глобальная настройка. Мне нужно сказать: «Запустите эти тесты в этом процессе и эти тесты в этом процессе». Есть ли способ сделать это?

Ответы [ 2 ]

2 голосов
/ 22 сентября 2011

Это проблема с глобальным состоянием, как вы упомянули: изменение его в одном тесте повлияет на другие тесты.

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

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

1 голос
/ 22 сентября 2011

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

Модульный тест должен установить требуемое состояние перед выполнением и разорвать его впоследствии. Это может быть сделано, например, с помощью испытательных приспособлений. С этим связан Arrange-Act-Assert (AAA), который представляет собой шаблон для написания модульных тестов.

В вашем случае статические данные плохие , что затрудняет тестирование !

Как насчет рефакторинга вашего кода , чтобы статические данные были доступны через некоторый интерфейс или через фабрику?

Не зная вашей проблемной области, невозможно дать точный ответ, что было бы лучшим. Однако подход, который вы должны использовать, заключается в извлечении общих статических данных, чтобы каждый тест мог настроить свой собственный набор данных. Теперь каждый тест может быть изолированным и будет иметь дело только с «собственными» данными.

Это дает дополнительные преимущества, такие как 1) модульные тесты просто будут иметь набор данных, достаточный для проверки одной вещи, 2) меньше зависимостей в вашей системе и 3) возможно, более быстрые / меньшие тесты.

Наконец, я согласен с Хади в том, что вы должны хранить модульное тестирование и интеграцию / функциональный тест отдельно. Это очень важно, потому что они проверяют вещи по-разному.

Удачи!

...