Cucumber JVM folder structure


In all the three tutorials i.e. Basic, Intermediate and Advanced, we have used cucumber jvm project template and used it and wrote our scenarios. However we never got a chance to talk about the overall project structure and why a certain file/folder exists the way it is structured. Obviously there is some convention (meaning a rule is defined) and there is some configuration (flexibility to modify some rules through configuration). In this post we will first talk about the folder structure we adopted all through the tutorials and set a stage, so that we don’t have to worry one fine day – Hmm, what is the purpose of this pom.xml for example? ;)

Cucumber Project structure(Sample):

This project/folder structure might change over time, however understanding what each package does is important for us here. Confirming to Cucumber standards, ideally there should be a support package, however I don’t have it now. Will introduce it soon. All I have to do is refactor and create a new package and move classes there and you know that it takes less than a minute for all that.


If imported into eclipse, it looks as below


  1. helpers package contains data helper and log4j classes. It can have more classes over time
  2. Modules package will have keyword driven framework details aka. keywords/module classes
  3. pageObjects have page object classes defined
  4. step_definitions package has all step definitions and hooks class as well as Cucumber Runner class (where we can set options)
  5. features package has all .feature files
  6. testData package has test data files eg. excel files
  7. pom.xml – since it is a maven project and has all dependencies as GAVs
  8. log4j.xml – config file for log4j
  9. – uses markdown so that it can be read easily on github

When cucumber runs, it first scans all the folders and there is a certain sequence of events that get triggered (we will cover this is a much later class as it might be digressing here). For example @Before will be called and that class will be instantiated (only once of course) and then cucumber kicks in executing the steps in a sequential manner. I have customized the classes, so that it aligns with how Cucumber ran in Ruby world [Not standardized because in Java any code should reside in a class, unlike Ruby, where you can have script as well as class]. We will over time standardize all of this. Oh , reminds me. In Java world, we also follow naming Convention like CamelCase for Class names – I have NOT followed the naming convention yet, because focus was to get it working first and so it is using snakecase as of now [Ruby uses snake case]. We will refactor this as well over time.

As you can see above I have parameterized the browser variable from either the Maven system property variable or environment variable. This is important because we want to be able to execute the same code via multiple browsers right. The post has already been written on the details on how to pass BROWSER variable as parameter – Intermediate Tutorial – parameterize BROWSER

The above RunCukesTest is the cucumber runner and you can see that we have mentioned several Cucumber options. Over time, we will see more options and how we can utilize tags, reports, CaseType etc.