We all know we should be testing more than we do, but it is one of those things that is frequently resisted, delayed, done incorrectly or simply forgotten. Creating and maintaining test cases can seem daunting when you are first getting started.
Since our job is to support business users, let’s look at the value of testing from a business perspective. Bring your own device (BYOD) is the now the norm. This can translate into a testing mine field, laden with different operating systems, frequent updates, a variety of screen geometries and device features.
Automated testing on mobile is possible, is necessary, and has business value. If you commit to releasing quality code, some questions you might ask yourself are how to start testing and how much effort this will be as developer effort translates into a short term expense to the business.
The good news is that testing can be simpler than you think. To illustrate this, stop now and watch the video below and see just how easy it is to build and run your first automated UI test. Be sure to come back and learn a few tricks to accelerate your progress.
[video:https://www.youtube.com/watch?v=d5LcGfLRAx0]As you can see, using the tools shown here, you now have no reason to avoid automated UI testing. While this only demonstrated iOS simulator tests, you can also run tests in a similar manner for Android physical devices (you will find that Android physical devices work much better for testing than the Android emulator). And even though MAF is a cross-platform application, you will find that the test scripts will differ between Android and iOS and you will need to record different tests for each platform.
In the video, I used javascript as my test language. A benefit of Appium is that it can generate test scripts in a variety of languages. For MAF, my suggestion would be to use Java and Javascript. Although I have generated and run tests in Java, “node” is the easiest route to get started. If you are testing even a small subset of supported devices, it is best to distribute the tests. If you use Java, you will need to download the server .jar for Appium and launch it with Java instead of node. A benefit of using Java is that the tests will execute and easily integrate into Maven or ant build scripts. Your selection may come down to your development team’s skills.
You will sometimes have to change the test code generated by Appium. Because you need to test multiple OS versions or devices, always strive to make your tests generic so that a single test can be defined for several devices, orientations and platforms. As shown in the code below, be sure to add comments. As you saw in the video, this code waits for an element to be rendered on the screen and it asserts that a value is rendered correct. You retrieve this value by calling “text()”, and using “should.eventually.equal()” to compare the value. If the value does not match, the test fails.
.elementByXPath(“//….UIAStaticText[5]”).text().should.eventually.equal(“TEST1”)
Another tool you should consider using is called “node-debug”. It is installed by typing “npm install -g node-debug”. When starting the test, use node-debug instead of node and it will launch the debugger in Chrome. This gives you a version of the Chrome developer tools so that breakpoints can be set and values can be changed at runtime. One thing to note with promise chaining that is used by web driver is that unless you package things in functions there will only be one breakpoint for all of your test functions. I recommend you put your code in a function so that it can be reused and more easily debugged. This is especially true if your automated tests need a login. If a login is required, a function can perform all of the tapping and typing so that copying code will not be necessary to setup tests with common steps.
This should get you ready to start writing some tests. Your next step is to get this integrated with your continuous integration (CI) build scripts so that every build will automatically be capable of testing every simulated or real platform you will need to test.
Manual testing can be painful for both developers and end users, fortunately you can spare everyone a lot of frustration with automated testing.