Gauge is a framework to write acceptance tests. A specification in gauge is basically a manual test script that has been made executable. Because of this it makes sense to reuse steps because they tend to describe low level operations.
Cucumber on the other hand facilitates BBD and you use Gherkin to capture the behavior of the system rather then the operations in a test. So instead of writing Login as user "Charles: and create project "Firebird"
which describes operations you'd write Given Administrator "Charles" created the project "Firebird"
.
This is quite a shift in perspective but helps communicate clearly what the software is supposed to do rather then how it supposed to be operated.
As a result you generally avoid writing low level operations in Gherkin. Rather you extract these into methods and call these methods from your step. You can then also reuse these methods in other steps.
For example suppose we have two steps that both create a user:
Given Administrator "Charles" created the project "Firebird"
And "Jullia" is added to project "Firebird"
@Given("{role} {persona} created the project {project}")
public void persona_with_role_creates_a_project(Role role, Persona persona, Project project){
createRole(role);
createUserForPersona(persona);
addRoleToUserForPersona(persona, role);
loginUserForPersona(persona);
createProject(project);
}
@And("{persona} is added to project {project}")
public void persona_with_role_creates_a_project(Persona persona, Project project){
createUserForPersona(persona);
addUserForPersonaToProject(persona, project);
}
@ParameterType("\"([^"]+)\"")
public Persona persona(String name){
// look up the persona by name from somewhere e.g. a config file
}
ect...
private void createRole(Role role){
// API calls to make a role here
// For test isolation it is important you don't reuse anything between tests.
}
private void createUserForPersona(Persona persona){
// API calls to create a user
// Don't forget to store the credentials for the persona somewhere
}
ect..
Note that quite allot of information might be needed to create a user and project. So rather then spelling all this information out in the feature file we reference a personas ("Charles", "Firebird") which act as templates for the type of project we create. We can provide these to the step definitions objects rather then plain strings by using parameter types ({persona}
, {project}
). These will convert the string into an object before the step is executed.