Proof-of-concept implementation of tooling to synchronize between Gherkin feature files and Spock specifications.
There are two parts to this approach:
- A Spock extension that hooks into the execution of your Spock specifications, and verifies that their structure matches (some caveats here) a directory of Gherkin feature files.
- A Gradle plugin that checks that each Gherkin feature file had an associated Spock specification run.
Together, this supports a workflow where you want to be sure that:
- If you create a new feature file, your build fails if there isn't an associated test.
- If you add a new feature to a feature file, your build fails if there isn't an associated test.
- If you change a feature in a feature file, your build fails if it doesn't match the feature in the specification.
- If you change a feature in a specification, your build fails if it doesn't match the feature in the feature file.
- If you create a new specification, your build fails if there isn't an associated feature file.
- Currently, the expectation is that you only enable this logic for a "featureTest" configuration, and within that configuration, require a one-to-one mapping between feature files and specifications.
- It would be reasonable to consider adding an "allowExtraSpecifications" setting or something similar, if we wanted to support a mix of feature tests and unit tests (for example) in a single configuration.
It is possible to run tests with spock-gherkin enabled in an IDE. By default, it will be disabled. To enable it, a system property "gherkin.enabled=true" to your run configuration. When running this way, it will not enforce that all features must have a matching specification executed, allowing for specifications to be run in isolation.
While this demonstrates the basic concept of automated enforcement of a matched workflow, there are various aspects that are unfinished:
- Support for data driven testing
- Support for Gherkin table parameters
- Support for tags
- Support for comments
- Support for "allowExtraSpecifications" option
- Exploration of automatic generation of feature files based on specifications, or specifications based on feature files
- Richer reporting
- Tighter IDE integration
- More test coverage
- Various code cleanup
- Clone the repo
(cd spock-gherkin-core && ./gradlew clean build publishToMavenLocal)(cd spock-gherkin-gradle && ./gradlew clean build publishToMavenLocal)(cd spock-gherkin-demo && ./gradlew clean build)
If desired, open the demo project in your IDE.
Now that you (hopefully) have it working, try making some changes in the demo project, and re-run the tests with ./gradlew testFeature. Here are some scenarios you can try out to test the behavior:
- No features: remove
src/featureTest/resources/*.feature - No specifications: remove
src/featureTest/groovy/*Spec.groovy - Specification without a feature file: remove a single file matching
src/featureTest/resources/*.feature - Feature file without a specification: remove a single file matching
src/featureTest/groovy/*Spec.groovy - Scenario/feature method mismatch: edit
src/featureTest/resources/manage_articles.featureto include "Scenario: Something else" or change "Articles List" to "Articles Listing" - Step count mismatch: edit
src/featureTest/resources/manage_articles.featureto add "And Pizza is awesome" at the end - Block type mismatch: edit
src/featureTest/resources/manage_articles.featureto change "Given I have articles titled Pizza, Breadsticks" to "Then I have articles titled Pizza, Breadsticks" - Block label mismatch: edit
src/featureTest/resources/manage_articles.featureto change "Given I have articles titled Pizza, Breadsticks" to "Given I have articles titled Pizza; Breadsticks" - Mismatched file name: rename
src/featureTest/groovy/ManageArticlesSpec.groovyor change/remove the FeatureFilename annotation insrc/featureTest/groovy/SalarySpec.groovy