We discussed about the Python setup for Appium on Friday and it’s time to move forward and see how things are getting done on Java. Furthermore, we’ve been covering the basic setup, installing all required bits and pieces, and preparing the environment for the first test runs in our Appium blog series.
The beauty of Java is in its extensibility and long existing history. Most developers these days have at least some experience in Java, which makes it easy to approach. You should check the Appium Java-client’s README, if you haven’t already!
Before you attempt to launch the Testdroid Java samples, remember to check that all the desired capabilities are correct. It may be a good idea to also set as many capabilities in Environment Variables as possible to reduce the amount of editing when creating additional test scripts. Frankly, this will save a lot of time and also makes your test run launching a way more robust (no typos or flaky issues with the script config).
TIP! Put as many desired capabilities in Environment Variables as possible. It saves time and reduces errors due wrong configuration or typos in desired caps.
Similar to the Python sample, our Java implementation uses the Environment Variables for capabilities such as
testdroid_password, app file location and Appium server:
private static final String TARGET_APP_PATH = "../../../apps/builds/BitbarSampleApp.apk"; private static final String TESTDROID_SERVER = "http://appium.testdroid.com";
String testdroid_username = env.get("TESTDROID_USERNAME"); String testdroid_password = env.get("TESTDROID_PASSWORD");
Notice how we create the test class by extending to another class called BaseTest.java:
public class SampleAppiumTest extends com.testdroid.appium.BaseTest.
Thanks to this extend, we get to use some of our self created code behind the scenes of the test class.
Let’s take a closer look at the BaseTest.java
Since we have both Android and iOS samples combined in the same Java project, we decided to create the convenience class called BaseTest.java. The class includes functions for both application upload to Testdroid Cloud and taking screenshots. Appium java-client’s screenshot implementation is based on Selenium Webdriver’s TakesScreenshot interface, which is basically too cumbersome to write multiple times.
While writing your own tests, extending to use such a convenience class can be a real time saver. This is what we do a lot also in our Image Recognition solution, which we will be covering later in this blog series.
Typically, our samples are built for Maven build automation tool. This tool is really handy as it automates downloading all required dependencies before building and executing the project. All the required dependencies and other project settings are described in the
Running tests in Testdroid Cloud
You can run test from your IDE or directly from command line using maven:
>mvn clean test -Dtest=SampleAppiumTest
or to be more precise:
>mvn clean test -Dtest=com.testdroid.appium.android.sample.SampleAppiumTest
or run all the tests:
>mvn clean test
When you have more than one test case to run, you should be aware of the fact that every test session to Testdroid Cloud can use only one instance of the Appium Webdriver. If you use driver.quit(), the current session towards the cloud will also end.
In other words, bundling multiple test cases to one test run session requires you to keep using the same webdriver instance in each of your test cases. To make sure each of your test case starts off from a clean slate, take a look at the driver command resetApp.
If you’re unsure of your possibilities with the java-client, you may find some ideas by checking the Appium Java-client API documentation.
See you again on Wednesday! Happy Testing!