Multi-level Gherkin-like language.
Using Cucumber, you would write something like the following and let developers translate it however they want:
Feature: User login
Scenario: Successful login
Given a user on the login page
When the user signs in with valid credentials
Then the user is logged in
Except several concepts in this spec are subject to interpretation.
/home
, check the title of the page, check the presence of a cookie, etc.)Using Glacio, you have room to answer these uncertainties together with all actors:
Feature: User login
Scenario: Successful login
Given a user with valid credentials
Insert generated user with valid credentials in database
Generate variable 'username'
Generate variable 'password'
Execute SQL
"""
INSERT INTO USERS(USERNAME, PASSWORD, ENABLED)
VALUES('${username}', '${password}', 1)
"""
And the user in on the login page
Open a 'Chrome' browser
Navigate to 'https://www.yourapp.com'
Click on the 'Sign In' button
When the user signs in
Fill 'username' input with '${username}'
Fill 'password' input with '${password}'
Click on the 'Sign In' button
Then the user is logged in
Relative URL is '/home'
In the end, like with Cucumber, developers will have to code some glue to make leaf-steps runnable. You can choose how many levels of explanation you have for each step. Go deep enough though and the code base will only contain generic little Lego pieces you can re-use to create new tests that are instantly runnable.
There is a common problem encountered using BDD tools like Cucumber. This is:
That is an historic clivage which tends to leave grey areas undiscovered until implementation time. Furthermore, non-technical actors can point out relevant aspects of implementation just as developers can do the same about the business part (aka specs).
As Seb Rose stated in this article, levels of readability can differ from the ones encountered in usual test segregation (unit, integration, acceptance, etc.).
This project is intended to solve this issue by supplying a shared medium for all actors to contribute together.
The language is inspired by Gherkin as it has many qualities (expressiveness, i18n, support of many programming languages). Substeps framework is also a source of inspiration, but the goal is to keep the Glacio language expressive by avoiding the need to switch between files to have the complete picture.
You may want to gather your domain vocabulary in one place, to avoid duplication and ambiguous definition (same step labels in different scenarios but with different meanings).
For this specific use case, like with Substeps, you can write definitions in .vocabulary
files.
user_login.feature
Feature: User login
Scenario Outline: Successful login
Given a user with valid credentials
And the user is on the login page with a <browser_type> browser
When the user signs in
Then the user is logged in
Examples:
| browser_type |
| Firefox |
| Chrome |
application.vocabulary
Insert generated user with valid credentials in database
* Generate variable 'username'
* Generate variable 'password'
* Execute SQL
```sql
INSERT INTO USERS(USERNAME, PASSWORD, ENABLED)
VALUES('${username}', '${password}', 1)
```
a user with valid credentials
* Insert generated user with valid credentials in database
the user is on the login page with a <browser_type> browser
* Open a '<browser_type>' browser
* Navigate to 'https://www.yourapp.com'
* Click on the 'Sign In' button
the user signs in
* Fill 'username' input with '${username}'
* Fill 'password' input with '${password}'
* Click on the 'Sign In' button
the user is logged in
* Relative URL is '/home'
Add the following dependency to your pom.xml
<dependency>
<groupId>com.github.fridujo</groupId>
<artifactId>glacio-junit-engine</artifactId>
<version>1.0.0-SNAPSHOT</version>
<scope>test</scope>
</dependency>
Add the following dependency to your build.gradle
repositories {
mavenCentral()
}
// ...
dependencies {
// ...
testCompile('com.github.fridujo:glacio-junit-engine:1.0.0-SNAPSHOT')
// ...
}
You need JDK-8 to build Glacio. The project can be built with Maven using the following command.
mvn clean package
Tests are split in:
mvn test
mvn org.pitest:pitest-maven:mutationCoverage
The project can be installed in a local Maven Repository for usage in other projects via the following command.
mvn clean install
The master of the project pushes SNAPSHOTs in Sonatype's repo.
To use the latest master build add Sonatype OSS snapshot repository, for Maven:
<repositories>
...
<repository>
<id>sonatype-oss-spanshots</id>
<url>https://oss.sonatype.org/content/repositories/snapshots</url>
</repository>
</repositories>
For Gradle:
repositories {
// ...
maven {
url "https://oss.sonatype.org/content/repositories/snapshots"
}
}