Подтвердить что ты не робот

Как мы наследуем классы тестов через модули библиотеки Android?

У меня есть проект Android Studio с двумя библиотечными модулями: foo-module и bar-module. Каждый реализует библиотеку, foo-module определяет интерфейс стратегии и bar-module в зависимости от foo-module и реализует такую ​​стратегию. foo-module имеет контрольные тесты (foo-module/src/androidTest/) для проверки его основного кода, используя реализацию стратегии заглушки, а bar-module должен иметь свои собственные контрольные тесты.

Я определил класс AbstractTests в foo-module/src/androidTest/, который выполняет большую часть фактического тестирования. У меня также есть класс StubTests в foo-module/src/androidTest/, который расширяет AbstractTests и реализует необходимые методы abstract для завершения тестового примера (обеспечивающего реализацию стратегии и т.д.). Все это отлично работает.

В bar-module/src/androidTest/ я создал класс BarStrategyTests, предназначенный для зеркального отображения StubTests, но предоставил стратегию, реализованную в bar-module. Тем не менее, BarStrategyTests не может видеть AbstractTests, хотя у меня есть compile project(':foo-module') в моем файле build.gradle, а основные (нетестовые) классы в bar-module могут отлично работать с основными (не тестируемыми) классами в foo-module. IOW, в то время как зависимость project() обрабатывает обычный код, он не обрабатывает код androidTest/. Я получаю "error: package com.commonsware.foo.test не существует".

Я также попробовал добавить androidTestCompile project(':foo-module') с тем же результатом.

Каков рецепт обмена тестовым кодом инструментария между модулями?

Временно, я могу клонировать AbstractTests, но это не большое долгосрочное решение.

Этот вопрос SO > охватывает аналогичную основу для обычной Java. Кто-нибудь пробовал варианты в одном ответе и получил их для работы на инструментальных тестах для Android? Первый вариант (переместить общий тестовый код в еще один модуль как обычный не-тестовый код) кажется правдоподобным, но я понятия не имею, будут ли другие двое работать с плагином com.android.library вместо плагина java.

4b9b3361

Ответ 1

В связи с тем, что все тестовые классы (unit и instrumentation) не являются частью какого-либо модуля, включая aar, они недоступны через зависимость от этого модуля. Я столкнулся с этой проблемой и решил ее, создав test-module и поместив в нее все необходимые классы (src/main/java). Таким образом, в вашем случае вы можете перемещать AbstractTests в этом модуле и использовать этот модуль как зависимость androidTestCompile.