This feature adds support for explicitly importing meta files into feature files. This is useful for cases where you have many meta files and it is not practical to load all of them for every feature file. It is also useful for cases where the current auto-meta-discovery and -m command line mechanisms are insufficient for controlling exactly what meta should be loaded when.
You can now manage and control exactly what meta will be loaded by your features without ever having to specify that meta on the command line. This can help avoid redundant meta loads and also greatly improve performance and usability when you have a lot of meta spread across many files.
For example, say you have 10 meta files in a directory and you only want to load one of them when executing a feature. Previously, you could do this through the -m command line switch as follows:
gwen -m metadir/module1.meta test.feature
You could also load all 10 meta files as follows:
gwen -m metadir test.feature
Remembering exactly which meta to load for which features is impractical, and blindly loading all meta files to execute a feature that only uses one or some of them is wasteful.
With meta imports, we can do away with having to use the -m option altogether by adding the following annotation to the Feature declaration in each feature file. For example, we can declare what meta the test.feature file should load by specifying an import annotation in the feature file itself as follows:
test.feature file:
@Import("metadir/module1.meta")
Feature: test feature
Scenario: scenario 1
Given I want ..
..
Now we can simply just specify the feature on the command line as follows:
gwen test.feature
Gwen will then load the meta file specified in the import before executing the steps in the feature.
You can add any number of meta imports to a feature. The following imports two meta files.
test.feature file:
@Import("metadir/module1.meta")
@Import("metadir/module2.meta")
Feature: test feature
Scenario: scenario 1
Given I want ..
..
You can also chain (or string together) meta imports across meta files. For example, if the module2.meta always requires module1.meta, then you can import the latter into the former:
metadir/module2.meta file:
@Import("metadir/module1.meta")
Feature: module 2 meta
@StepDef
Scenario: ..
Given I want ..
..
Now any feature that imports module2.meta will also implicitly import module1.meta. For example, if we declare test.feature to import module2.meta as follows:
test.feature file:
@Import("metadir/module2.meta")
Feature: test feature
Scenario: scenario 1
Given I want ..
..
..Then both module1.meta and module2.meta will be loaded (in that order) when the feature is executed without you having to specify any meta on the command line:
gwen test.feature
The path to the meta file in all import annotations is relative to the working directory where Gwen is invoked.
If a recursive (or cyclic) import is detected in an import chain, Gwen will report it by throwing an exception with a message specifying which import annotation was the culprit and the file it was declared in.
Meta imports are always loaded before any auto discovered meta files or -m command line meta files are loaded, and therefore have the least precedence so their contents can be shadowed.
This feature adds support for explicitly importing meta files into feature files. This is useful for cases where you have many meta files and it is not practical to load all of them for every feature file. It is also useful for cases where the current auto-meta-discovery and
-m
command line mechanisms are insufficient for controlling exactly what meta should be loaded when.You can now manage and control exactly what meta will be loaded by your features without ever having to specify that meta on the command line. This can help avoid redundant meta loads and also greatly improve performance and usability when you have a lot of meta spread across many files.
For example, say you have 10 meta files in a directory and you only want to load one of them when executing a feature. Previously, you could do this through the
-m
command line switch as follows:You could also load all 10 meta files as follows:
Remembering exactly which meta to load for which features is impractical, and blindly loading all meta files to execute a feature that only uses one or some of them is wasteful.
With meta imports, we can do away with having to use the
-m
option altogether by adding the following annotation to theFeature
declaration in each feature file. For example, we can declare what meta thetest.feature
file should load by specifying an import annotation in the feature file itself as follows:test.feature file:
Now we can simply just specify the feature on the command line as follows:
Gwen will then load the meta file specified in the import before executing the steps in the feature.
You can add any number of meta imports to a feature. The following imports two meta files.
test.feature file:
You can also chain (or string together) meta imports across meta files. For example, if the
module2.meta
always requiresmodule1.meta
, then you can import the latter into the former:metadir/module2.meta file:
Now any feature that imports
module2.meta
will also implicitly importmodule1.meta
. For example, if we declaretest.feature
to importmodule2.meta
as follows:test.feature file:
..Then both
module1.meta
andmodule2.meta
will be loaded (in that order) when the feature is executed without you having to specify any meta on the command line:The path to the meta file in all import annotations is relative to the working directory where Gwen is invoked.
If a recursive (or cyclic) import is detected in an import chain, Gwen will report it by throwing an exception with a message specifying which import annotation was the culprit and the file it was declared in.
Meta imports are always loaded before any auto discovered meta files or
-m
command line meta files are loaded, and therefore have the least precedence so their contents can be shadowed.