Two weeks ago, the School of Automation of Development Processes (CAD) in St. Petersburg Yandex ended .
Looking ahead, I’ll say that the teachers did 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 terribly annoying, causing thoughts like "but now, instead of performing routine operations, I could write beautiful code ...".

You can read more about how they succeeded 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 to organize Continuous Integration for Android.
Inspired by Alexey Korovyansky 's report on MBLTDev, and especially the results of the Google Test Automation Conference 2014 regarding testing Android applications , I implemented a simplified analogue of our training project for a different platform, transferring everything I could and managed there. On this the preface ends and the actual description of automation begins.

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. The text on the button can be changed in a couple of minutes (including the start time of the IDE), assemble the project in a couple of minutes - and then check for several hours to see if the layout went in all places where this button was used at all control screen resolutions. If this process is not automated, of course.

Fortunately, in December 2014, Google still pleased android developers by includingEspresso framework in the Android Support Repository. Hurrah! 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é already wrote , so I will limit myself to the observation 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 github project, link at the end of the article.

2. Automated assembly

In our enlightened age, there is probably no need to describe the benefits of using assembly systems.
In CAD, we used Maven, but under Android Studio with its Gradle support out of the box, something else is simply inconvenient to use.
To run the tests, tasks were used.

• connectedAndroidTest - from the list of typical gradle tasks
• spoon - appears when installing the appropriate plugin. A very useful development of the Square team led by the notorious Jake Wharton. Allows you to run tests on multiple connected android devices at the same time, take screenshots from them, and much more

3. Automated test run

If you by some miracle do not use Maven or Gradle, then you can not read further - no continuous integration server will be friends with your project.
And if you use it, then after several launches of several tens / hundreds of tests for the project, you have a great desire for this to happen all on its own, and preferably, as far as possible from your processor :-). Here Jenkins comes to our aid (TeamCity, Atlassian Bamboo, underline what is needed). I used Jenkins, which we were taught in CAD. A lot has been written about Jenkins and even directly its relationship with Android applications on Habré .
In our case, in addition to the default plugins,

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

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

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, you need to translate various settings into the code. In a model project, this is implemented using gradle build flavors, the variables are moved to a separate file with constants, which the plug-in substitutes into the desired assembly.

So, what does the partially automated development process of a model android application look like at the moment:
1. The written code goes to github.
2. Jenkins catches a hook with github and starts the assembly on all android devices that are running / connected to the server / node
3. Based on the results of the assembly, Jenkins unsubscribes to github / sends an email to the developer / lights a red or green light above the door (underline as necessary)
4. If the assembly is successful, the installation file is uploaded to the test devices, and the handbrake testers are notified that they can get started (if necessary)
5. It is even possible to automatically publish the assembled project to GooglePlay using Google Play Android Publisher Plugin

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

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

The project used libraries:

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

Taking this opportunity, I want to sincerely thank our instructors in CAD and Yandex in general.
Once again you made the world a little better. Thanks! :-)