Have you used our Virtual Device Testing for Android? Was your test successful or did it fail unexpectedly? We’ve got some updates for you based on your feedback so far.
As more and more users have tried it, we get a lot of valuable feedback so we can improve and re-think the features. We are very grateful for feedback so kindly let us know if you encounter anything we’d need to know or ping us on our on-site chat (on Bitrise.io) to share your experience.
Fixed environment variables 🤖
In our latest version (0.9.9) we fixed the Environment Variable input, which — as it turned out — ignored the set input values so it did not set the env vars before testing. This was an almost invisible bug so if you ever tried to use an env var in your test and you got unexpected results, refresh your Virtual Device Testing for Android step to 0.9.9+ in your workflow(s) and run it again.
Default test type 🛠
Another change was that we changed the default test type to robo. If you use it with the latest version of gradle runner step, you only need to add the VDT step after the gradle runner and then you can run a robo test without any further configuration. A bit later gradle runner also got an update, that is an extra export filter input and a separate output environment variable: BITRISE_TEST_APK_PATH. With this added, if you want to run an instrumentation test instead of a robo, you only need to set the test type to instrumentation and then add assembleDebugAndroidTest to the gradle task field to make the gradle runner build a test apk too. So for example, it'll be assembleDebug assembleDebugAndroidTest, that will build both at the same time.
Small but mighty updates 💪
- 0.9.8 version also has a new, noteworthy input: Use Orchestrator. Soooo now it is possible to run an orchestrated test too.
- We’ve implemented retry logic, so if we identify a known minor glitch we will retry the tests, so you don’t have to.
Happy testing!
Originally published on the Bitrise Blog.
