I am currently testing my sample app using Android instrumentation test. By default, the project creates AndroidTest folder for me. I simply just added more test cases into the folder.
I used to use expresso to trigger the UI buttons, but now I want to test use androidTest only, However, the androidTest does not seem to test my release build. I have two variants productionRelease and stageDebug in this case.
Every time I started the project by
./gradlew mysample:connectedCheck
or
./gradlew mysample:connectedAndroidTest
it tests only
Task :mysample:connectedStageDebugAndroidTest
If I want to manually start a task
./gradlew mysample:connectedProductionReleaeAndroidCheck
It complains tasks not found in mysample
* What went wrong:
Task 'connectedProductionReleaseAndroidTest' not found in project ':mysample'.
Isn't connectCheck supposed to test all the variants in my project? (StageDebug and ProductionRelease)
from task --all
mysample:connectedCheck - Runs all device checks on currently connected devices.
mysample:connectedAndroidTest - Installs and runs instrumentation tests for all flavors on connected devices.
Just tried... one can simply run ./gradlew mysample:testDebugUnitTest and ./gradlew mysample:testReleaseUnitTest - which runs the tests for either debug or release build. one can add the annotation #RequiresDevice to tests, in case eg. one requires hardware sensors.
productionRelease and stageDebug seem over-complicated (and it also not matches the rest of the naming - unless there would be productionDebug and stageRelease as well), resulting in even longer task names, would suggest to shorten...
buildTypes {
debug {}
release {}
}
Here when I run ./gradlew mysample:connectedAndroidTest I rather get a
Execution failed for task ':mysample:connectedDebugAndroidTest'.
com.android.builder.testing.api.DeviceException: No connected devices!
After closing Android Studio (and the ADB daemon it started), I can run the tests on hardware device. there only is a installDebugAndroidTest task, but no installReleaseAndroidTest task. testBuildType 'release' might run the tests against the release build - the problem is just that androidTestImplementation most likely is not contained then (quite useless).
Related
I have Jenkins job that builds an apk. I also have a gradle command that will run some tests on an Android device. I would like my jenkins job to be able to run this gradle command, but if the tests fail I don't want jenkins to fail the entire build. I just want it to mark the tests as failing and then notify people that the tests have failed. But failing tests by themselves should not mark the whole build as a fail. Is there a way to do this?
I believe you use the ignoreFailures = true flag in your gradle.build's Test task config.
If that doesn't work, you can use Jenkins try/catch/finally:
try {
// test step here
} catch (error) {
// other steps if test step fails
}
When running Espresso tests with ./gradlew connectedDebugAndroidTest, we're having this issue:
com.android.build.api.transform.TransformException:
com.android.ide.common.process.ProcessException:
java.util.concurrent.ExecutionException:
com.android.dex.DexIndexOverflowException: method ID not in [0,
0xffff]: 65536
As we're using Multidex at the main app and just adding the Espresso dependencies on the instrumented test one, we don't get why it doesn't work :·( In addition, if we run the tests via IntelliJ instead of Gradle, it works :·|
By the way, we need to run them via Gradle to automate them on the CI tool.
More information? There's a link to a related issue on Google's issue tracker: https://issuetracker.google.com/issues/37017515 :sad:
The task connectedDebugAndroidTest will try to build test apks for every module in the project, so if you project has multiple modules, you need to enable multidex in every one of them. This is usually done setting
android.defaultConfig.multiDexEnabled true
in build.gradle for each module.
You could skip all of this for modules that don't have any tests if you just don't try to execute the task in those. e.g, if only the app module has instrumentation tests, you could execute app:connectedDebugAndroidTest instead to avoid the possible multidex errors. This is actually what the run configuration created by Android Studio does by default, and probably the reason why your tests are running just fine when you launch them form the IDE.
I'm creating a compile-time annotation processor to generate some code on Android.
To trigger the annotation processor I'm using the android-apt plugin from hvisser https://bitbucket.org/hvisser/android-apt/overview
At the moment, on every change I do on my Processor extends AbstractProcessor I have to run a full /.gradlew clean build to see the results, and that is kinda of a slow process, even for a tiny sample project.
So my question, is there any of the gradlew tasks I could use to trigger the annotation processor?
The output from my current ./gradlew tasks is:
------------------------------------------------------------
All tasks runnable from root project
------------------------------------------------------------
Android tasks
-------------
androidDependencies - Displays the Android dependencies of the project.
signingReport - Displays the signing info for each variant.
Build tasks
-----------
assemble - Assembles the outputs of this project.
assembleAndroidTest - Assembles all the Test applications.
assembleDebug - Assembles all Debug builds.
assembleDebugAndroidTest - Assembles the android (on device) tests for the Debug build.
assembleRelease - Assembles all Release builds.
build - Assembles and tests this project.
buildDependents - Assembles and tests this project and all projects that depend on it.
buildNeeded - Assembles and tests this project and all projects it depends on.
classes - Assembles classes 'main'.
clean - Deletes the build directory.
compileDebugAndroidTestSources
compileDebugSources
compileDebugUnitTestSources
compileReleaseSources
compileReleaseUnitTestSources
jar - Assembles a jar archive containing the main classes.
mockableAndroidJar - Creates a version of android.jar that's suitable for unit tests.
testClasses - Assembles classes 'test'.
Build Setup tasks
-----------------
init - Initializes a new Gradle build. [incubating]
wrapper - Generates Gradle wrapper files. [incubating]
Documentation tasks
-------------------
javadoc - Generates Javadoc API documentation for the main source code.
Help tasks
----------
components - Displays the components produced by root project 'Decorator'. [incubating]
dependencies - Displays all dependencies declared in root project 'Decorator'.
dependencyInsight - Displays the insight into a specific dependency in root project 'Decorator'.
help - Displays a help message.
projects - Displays the sub-projects of root project 'Decorator'.
properties - Displays the properties of root project 'Decorator'.
tasks - Displays the tasks runnable from root project 'Decorator' (some of the displayed tasks may belong to subprojects).
Install tasks
-------------
installDebug - Installs the Debug build.
installDebugAndroidTest - Installs the android (on device) tests for the Debug build.
uninstallAll - Uninstall all applications.
uninstallDebug - Uninstalls the Debug build.
uninstallDebugAndroidTest - Uninstalls the android (on device) tests for the Debug build.
uninstallRelease - Uninstalls the Release build.
Verification tasks
------------------
check - Runs all checks.
connectedAndroidTest - Installs and runs instrumentation tests for all flavors on connected devices.
connectedAndroidTestDebug - Installs and runs the tests for Debug build on connected devices.
connectedCheck - Runs all device checks on currently connected devices.
deviceAndroidTest - Installs and runs instrumentation tests using all Device Providers.
deviceCheck - Runs all device checks using Device Providers and Test Servers.
lint - Runs lint on all variants.
lintDebug - Runs lint on the Debug build.
lintRelease - Runs lint on the Release build.
test - Runs the unit tests.
testDebug - Run unit tests for the debug build.
testRelease - Run unit tests for the release build.
Other tasks
-----------
jarDebugClasses
jarReleaseClasses
Source generation happens when you compile. So running gradlew cleanCompileDebugSources compileDebugSources is what you need. This is the same was what Android Studio is running when you make your project from the build menu.
If you are developing your annotation processor as part of your project, you can use the processor option in android-apt without needing to package your processor project. This is assuming you have your processor module as a apt project(':myprocessor') dependency (compile will also work).
apt {
processor "my.class.name"
}
I currently have an Android project using gradle and integrated with travis.ci which has different productFlavors and buildTypes. When the "connectedCheck" task is then executed on travis.ci, it tries to package all build variants (all combinations of flavors and types). Some of them fail as the release builds need password input which I can't automate at the moment. Is there a way to tell travis.ci to build and test only a certain build variant of an Android project?
Say you only want to run the product flavor Trial and the build type Debug.
Instead of running ./gradlew assemble connectedCheck, which is similar to what you're doing, run this instead:
./gradlew assembleTrialDebug connectedCheckTrialDebug
So here's how I made it work:
Run a connectedAndroidTest<productFlavor><buildType> task instead of connectedCheck.
Also set the assemble task in the install section of the .travis.yml:
install: - TERM=dumb ./gradlew -s assemble<productFlavor><buildType>
I've currently set my TeamCity instance to run connectedCheck on all my Android-projects. This is fine, all tests run and everything is good. Except, connectedCheck runs all tests for all product flavors. I currently have a lot of flavors, so this is wasted work for my projects as I do not really have any different code in the flavors. Any idea how I can make connectedCheck only run for one flavor?
./gradlew connected[Flavor]DebugAndroidTest
./gradlew connectedBuildVariantAndroidTest
Example:
./gradlew connectedDevelopmentDebugAndroidTest
As vida said you can run ./gradlew tasks to check all possibilities to run gradle commands.
I'd like to suggest the following:
./gradlew tasks | grep connected.
This filter all connectedAndroidTest variants that can be runned.
I see there is a new task since I checked this the last time, "connectedAndroidTestProductFalvor_buildvariant".
I haven't had time to check this task yet, but the description reads "Installs and runs the tests for build ProductFlavor_buildvariant on connected devices."
Will post a result when I've been able to test this.
and if you want to generate the apk for the android test :
./gradlew assemble[flavour]DebugAndroidTest