Блог

Я использую бета-версию OpenWrap 2.0. OpenWrap содержит поддержку для запуска модульных тестов, мой вопрос в том, как именно это работает?

Должен ли я рассматривать это как тестовый запуск, который принимает встроенную оболочку, ищет тесты, включенные в оболочку, и пытается их запустить? Требуется ли включать тесты в обертку?

Как работает разрешение зависимостей в контексте тестов? Я могу указать область тестирования, которая добавляет дополнительные зависимости, необходимые для тестов. Когда используются эти зависимости? Я предполагаю, что он используется для создания тестовых проектов и для запуска тестов с помощью test-wrap? Однако, когда я включаю тесты в перенос, разве эти зависимости в тестовой области не должны также считаться зависимостями для переноса, или они используются только как зависимости, когда я пытаюсь выполнить «перенос тестов»?

Еще одна вещь, о которой я задавался вопросом в контексте тестов, — это разница между зависимостями во время компиляции и во время выполнения.

В качестве примера у меня есть project API, который определяет API. Рядом с этим проектом у меня есть 2 других проекта Impl1 и Impl2, каждый из которых определяет другую реализацию этого API. И рядом с этим у меня есть API тестового проекта.Тесты, содержащие тесты против API. Тесты используют внедрение зависимостей, чтобы внедрить либо Impl1, либо Impl2 для запуска тестов. В данном случае API.Проект Tests имеет только зависимость во время компиляции от API (и должен иметь только то, что доступно как зависимость во время компиляции). Однако при выполнении тестов проект зависит во время выполнения от Impl1 или Impl2. Любые предложения о том, как это упаковать?

test-wrap сможет запускать test-runner для тестов, которые поставляются как часть pacakge (в /tests ).

Реализация прямо сейчас больше не актуальна, в основном потому, что пакеты не включают testdriven.net test runner, что делает выполнение этих тестов довольно сложным. По этой причине я еще не пересматривал наши планы на этот счет.

OpenWrap 2 использует области для определения зависимостей, которые применяются только к определенному подмножеству вашего кода. В случае тестов, при условии, что у вас есть правильная инструкция dicrectory-structure в дескрипторе, ваш проект будет использовать эти зависимости в правильной области видимости.

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

Тот же механизм будет