Two weeks ago, the School of Development Process Automation (SHAPR) ended in St. Petersburg Yandex.
Looking ahead, I will say that the teachers managed the most important thing: in less than three months, they “spoiled” our perception of the development process, as promised at the beginning of the School. Manual testing and assembly began to be terribly annoying, evoking thoughts like "and now, instead of performing routine operations, I could write beautiful code ...".

You can read more about how they did it here and a little more here .

In the practical part of the training, we implemented a web blog based on the technologies listed above.
As an android developer, I was interested in the possibility of using these technologies and tools for organizing Continuous Integration for Android.
Inspired by the report of Alexey Korovyansky on MBLTDev, and, especially, the results of Google Test Automation Conference 2014 regarding the testing of Android applications , I implemented a simplified analogue of our training project for another platform, transferring everything that I could and succeeded. At this preface ends and begins the actual description of automation.
')

1. Automated Testing

We say automation, we mean - tests; we say tests, we mean - automation.
Testing is often one of the most resource-intensive parts of the development process. You can change the text on the button in a couple of minutes (including the IDE launch time), build the project in a couple of minutes - and then check for a few hours if the layout did not go in all the places where the button was used at all the screen resolutions. If this process is not automated, of course.

Fortunately, in December 2014, Google still pleased the android developers by including the Espresso framework in the Android Support Repository. Hooray! Finally, we have a powerful, fairly stable tool for writing system tests, which is supported by the developer of the operating system (among other things, it gives hope that the tests will not sprinkle with the release of the new version of Android).
About Espresso on Habré has already been written , so I’ll confine myself to noticing that in the current version it allows you to synchronize operations in tests not only with UI Thread and AsyncTasks, but also with arbitrary background operations (http requests, for example). An example of the implementation of system and integration tests can be found in my project on github, the link at the end of the article.

2. Automated build

In our enlightened age, there is probably no need to describe the benefits of using assembly systems.
In SHAPR, we used Maven, but under Android Studio with its Gradle support “out of the box,” something else is just uncomfortable to use.
Tasks were used to run tests.

• connectedAndroidTest - from the list of typical gradle tasks
• spoon - appears when you install the appropriate plug-in. Very useful development team Square under the guidance of the notorious Jake Wharton. Allows you to run tests on several connected android devices at the same time, take screenshots of them, and much more

3. Automated run tests

If by some miracle you are not using Maven or Gradle, then you can not read further - not a single server of continuous integration with your project will be friends.
And if you use it, after several launches of several tens / hundreds of tests to the project, you have a great desire to have it all happen on its own, and, preferably, as far as possible from your processor :-). This is where Jenkins comes to the rescue (TeamCity, Atlassian Bamboo, underline). I used Jenkins, which we were taught in the Shapr. About Jenkins and even directly his relationship with Android applications on Habré is also written a lot.
In our case, in addition to the default plugins, we used

• GitHub plugin, GIT plugin, GitHub API Plugin - to get code and capture events from github
• Gradle plugin - to run gradle tasks
• Android Emulator Plugin - to run an application on an emulator (then abandoned this idea in favor of spoon)
• HTML Publisher plugin - for publishing a description of the results of executing tests of an arbitrary format on the task page
• JUnit Plugin - to publish the results of unit tests

In general, the launch of tests on real devices and virtual images of genymotion showed better results in speed, stability and realism than the standard Android emulator from Google, so I refused to use it in testing at the moment.

4. A few words about the separation of environments

We are talking about using different, for example, databases for testing and production. To do this, the code must translate various settings. In the model project this is implemented with the help of gradle build flavors, the variables are put into a separate file with constants, which the plug-in substitutes into the desired build.

So, what is the partially automated development process for a model android application at the moment:
1. The written code leaves on github.
2. Jenkins catches a hook with github and runs the build on all android devices that are running / connected to the server / node
3. According to the results of the assembly, Jenkins unsubscribes on github / sends a letter to the developer / lights a red or green light bulb above the door (underline the appropriate)
4. If the build is successful, the installation file is uploaded to the test devices, and the handy testers receive a notification that they can start work (if necessary)
5. It is even possible to automatically publish the assembled project to GooglePlay using the Google Play Android Publisher Plugin.

TODO : Unfortunately, we have not yet had time to raise the SonarQube , although at the Shapr we managed to visually evaluate the usefulness and importance of code analysis tools. Yes, and code coverage in the test project is not considered yet. I did not have time to use the mechanism of dependency injection, which is very convenient for writing well-tested code - for Android, there is a wonderful Dagger library for this. In general, there is more to do.

Promised link to a model project (a blog with the ability to add / remove posts / comments) and a dozen tests to it. Do not judge the code too strictly, because in order to test it makes sense, it must break sometimes, right? ;-)

The project used libraries:

• robospice
• retrofit and okhttp
• androidannotations
• cupboard
• well and of course espresso

Taking this opportunity, I want to sincerely thank our instructors at Shapr and Yandex as a whole.
You once again made the world a little bit better. Thank! :-)