Structure of a Gingerspec based project
If you followed the instructions for creating a new Gingerspec-based project as described here you will be presented with the following folder structure:
(For this example, let's assume groupId=eu.vptech, artifactId=mytestproject where the variables used when creating the project as described here) (default values for package and version)
This package contains classes that are the "glue" code of your application. In cucumber, glue code is the code that interacts directly with your application. Typically, glue code is the steps definitions (the actual java code that is executed behind each step), but it can also contain cucumber hooks. GingerSpec contains a lot of ready-to-use gherkin steps, but there might be cases when you need to implement your own logic or create your own steps to use in your feature files (check the examples already provided). Noticed that this class is included in the "glue" parameters in the ‘@CucumberOptions’ annotation of the Runner classes (check section B for more info). You can create as many classes with step definitions as you like and cucumber hooks here.
This is the default location of the TestNG runner classes (GingerSpec uses TestNG for test execution in the background). These files define the location of the step definition classes and provide all the metadata information required for test execution. These classes are annotated with ‘@CucumberOptions’ annotation to define the location of feature files, step definitions ("glue code"), what reporting integrations to use, etc. You can name these classes any way you want, however, it is strongly recommended to include the "IT" suffix at the end, so GingerSpec can recognize that these are classes that contain integration tests. Check how this annotation is used in these examples and all the different configuration options here.
You can use these files to store environment-dependable variables. For example, the URL of a particular server is different for production/uat/preproduction environments. For more information about this, check using environment dependent variables.
These are the feature files of cucumber that contain all the scenarios/steps to be executed. GingerSpec already provides a lot of ready-to-use steps for many technologies (you can get a list of ALL the steps contained in GingerSpec by looking at the library's javadoc. Remember that you can also create your own step definitions (check section A).
The schemas folder is used to store any other important information necessary for the tests. For example, you can store in a json file the content of a POST body request, and later, in your tests do something like "When I send a 'POST' request to '/posts' based on 'schemas/mytestdata.json' as 'json'". You can also store any other type of file that is needed for your tests here.
This file is a configuration file to make your tests run on the gitlab CI pipeline. The file is well documented and provides some ready-to-use examples.
This is a template for a changelog file. Whenever you make changes to your application, you can use this file to list the changes between versions, in that way, the users of your app can have an idea of when certain change was introduced and why.
XML file that contains information about the project and configuration details used by Maven to build the project. In case you need to use any special dependency for your project or external library, it must be added here.
All projects are created with a template README file. Use it to provide information about your project, what it does, what's its purpose, and how to execute your tests. Keep your README file updated!.