The testing that we will do now is similar to the kind of tests that a person using the app could do. In fact, in companies that have QA (Quality Assurance), people use these tools as a complement to manual testing.
UI tests can be automated as well, but they differ from unit and integration tests; these are actions performed on the screen, from clicking on a button to completing a registration process with recorded events.
We will start with stress testing using The Monkey.
The Monkey is a program that can be launched from the command line with ADB. It generates random events in our device or emulator, and using a seed, we can reproduce the same random events. To clarify, let's consider an example with numbers. Imagine that I execute Monkey and it produces random numbers from 1 to 10; if I launched it again, I would get different numbers. When I execute The Monkey with a seed (this seed is a number), I get a set of different numbers from 1 to 10, and if I launch it again with the same seed, I will get the same numbers. This is useful because if we use a seed to generate random events and have a crash, we can fix this crash and run the same seed again to ensure that we fixed the problem.
These random events can vary from clicks and scroll gestures to system level events (such as volume up, volume down, screenshot, and so on) We can limit the number of the events and the type as well as the packages in which we run it.
The basic syntax in the terminal is the following command:
$ adb shell monkey [options] <event-count>
If you have never used ADB, you can find in it the platform-tools folder inside the Android SDK directory wherever it is installed in your system:
../sdk/platform-tools/adb
When we open a terminal and navigate to this directory, we can write the following line of code:
adb shell monkey -p com.packtpub.masteringandroidapp -v 500
When you try to use adb and the output is command not found, you can restart adb with adb kill-server, adb start-server, and use ./adb (dot slash adb) if you use Linux or Mac.
We can increase the number of events to 5000 or produce infinite events, but it is always recommended to set a limit of numbers; otherwise, you will have to restart the device to stop The Monkey. When you execute the command, you will be able to see the random events produced, and it will indicate the seed used in case you want to repeat the same chain of events:
Depending on the app, we might need to adjust the time between events with the throttle milliseconds property in order to simulate a real user.
With the next testing tool, we will do a different kind of UI testing with the purpose of following a flow. An example of this would be if we have a registration process composed of three screens with different forms and want to record a test where a user fills up the form and continues through the three screens logically. In this case, The Monkey will not really help; with a very big number of events, it will eventually complete all the input fields with random characters and click on the buttons to move to the next screen, but this is not exactly what we want.
The purpose of recording a sequence of tests such as the registration process is to have this test saved in order to be able to run it again when we make changes to our code. We might have to modify the network requests of the registration process without changing the UI, so these tests are perfect. We can just run them after finishing the modifications, and we don't have to manually complete the registration or fill the forms ourselves. We are not being lazy here; if we have hundreds of tests, this will be a lot of effort for one person. Also, with automated tests, we can ensure that the sequence of events is always the same.
MonkeyTalk is a free and open source tool, which comes in two versions; we'll be using the community version for our example.
Note
A list comparing the community and professional versions can be seen on their website at https://www.cloudmonkeymobile.com/monkeytalk.
MonkeyTalk can be used on real devices and emulators. It works by recording a list of events while we are in Record mode:
Once we enter this record mode by clicking on Record in the tool, every event will be recorded in an order, with the action performed and the argument used. In the preceding screenshot, we can see how tapping on TextView and writing some input on it are recoded as two events.
We could create this in a script file, and MonkeyTalk will reproduce it; so, we have the option to create our own sequence of events without recording. For the preceding events, we will write a script such as the following:
Input username tap Input username enterText us
If we click on the Play now button, we will see all these steps executed on any device. We could record the scripts on an Android phone and play them on an iOS device.
Apart from recording and playing scripts, we can have verification commands. For instance, if we had a button that cleared all the input fields, we can add a verification command during the script using currentValue:
Input username tap Input username enterText us Input clearform click Input currentvalue ""
This will report the result of the verification during execution, so we will be able to check whether all our verifications are passed correctly. For example, clicking on the button to clear the forms would need a click listener that clears every input text. If, for some reason, we make modifications and the IDs of the elements change, a MonkeyTalk test will report the problem with a command failed verification.
Wouldn't it be nice to have a tool that runs these UI tests for us, along with unit and integration tests, every time we make changes in our app? This solution exists, and it's called Continuous Integration.