Android & BDD tests. Part 2 – Time for Cucumber

In the first post of the series I set the challenge up and I’ve been thinking all this time – what BDD framework is the best for my purposes? After analyzing the existing options on the market, I understood that there are 2 leaders: JBehave and Cucumber. Both of them have the same syntax for writing BDD scenarios. Moreover, their mapped Java methods are annotated by the same set of annotations. The only one major difference is how to configure runners of these frameworks, and Cucumber looks much clearer from this perspective. So, let’s try to solve this puzzle using it! And before some actions with the project, a couple of sentences about what Cucumber is…

The Behavior-Driven Development itself assumes that we write scenarios first then develop features. In the context of testing, we create scenarios that we’d like to test and then write the test code. Cucumber provides an API for understanding the Gherkin language and turning it into the code that we can use in our tests, execute and get some results. A typical scenario written using the Gherkin language looks like:


This is some kind of a dummy scenario that I just invented but you may notice some keywords in the example above. These are Given, When, Then and And. We can easily describe most of the functional test scenarios using these words, and that means that everybody will be able to understand a feature as well as automated tests linked to it. Actually, that was one of the main ideas of BDD – to make everything easy to understand even for stakeholders that have no clue about coding stuff. But how does the scenario above look like in a Java class? More or less, like this:


Again, the code above is an approximate example of how methods can be structured and designed. Cucumber offers more extended logic of annotations using regular expressions for methods parameters, names, etc. Please check this page if you need more examples and explanations.


Back to the challenge project

Okay then, let’s go to the androidTest folder of our Timber project under test and create the assets/features sub-folders inside. I will use the feature folder for storing .feature files with BDD scenarios. Since there are 2 scenarios that I was gonna cover so far (I think I’ll add more later on), I’ll create 2 separate files with the following tests:


A .feature file is a file where Cucumber looks for BDD scenarios. However, in order for it to understand where to look for, I have to specify their location explicitly in the android section of the application build.gradle file:


After that, the Cucumber instrumentation test runner will be able to find the feature folder that I created before and parse its content, i.e. scenarios. Oh, I mentioned the Cucumber test runner but didn’t explain its place in the test project at all. Let’s fix this misunderstanding.


Importing Cucumber core

In order to use Cucumber in the project, it should be added as a dependency in the build.gradle file:


The first dependency is the port of cucumber-jvm for Android. The second dependency is the module for dependency injections (used by Cucumber for better organizing of glue code of Step Definitions). And the third dependency is the native Android support test runner which will be extended by Cucumber for running its BDD tests.

Now nothing blocks me from finalizing preparation for writing Steps Definitions, nothing except defining a custom Cucumber test runner that will work on top of the Android Instrumentation and handle the application under test. Hence, I’ll create a new Java class with the following content and put it to the Runner sub-folder of the project:


The code above is pretty self-explanatory, you won’t change it most likely, and neither will I. The final step is to register this BDDRunner as a test instrumentation runner in the build.gradle file. It should be done in the defaultConfig section:



The infrastructure for writing Steps Definitions is ready! In the next post I’ll think on several things:

  • what’s the best framework for Android testing that fits my needs;
  • how to split test logic from accessing the player’s controls;
  • what design patterns could be used.

Stay tuned!

Like this post?

Subscribe to updates from my blog, if you don't want to miss more interesting future posts and materials

Please check your email and confirm subscription

Pin It on Pinterest

Share This