cucumber/cucumber-jvm — pull request #420 by signed (2012-11-08 13:43:08+00:00)
Title: Append starter class to feature paths

For our cucumber test we use a different starter class for each feature file.
This way we can run a single set of features that belong together.

```
src/test
/java/apackage
FeatureOne.java
FeatureTwo.java
/resource/apackage
FeatureOne.feature
FeatureTwo.feature
```

The starter implementation looks like this for each feature only differing in the feature path.

```
package apackage;

@RunWith(Cucumber.class)
@Cucumber.Options(features="classpath:apackage/FeatureOne.feature")
public static class FeatureOne{
}
```

This results in a lot of duplication.

To reduce the ammount of duplication this patch introduces a new boolean option ``appendStarterClassToFeaturePaths`` in ``Cucumber.Options``.
By default this option is set to ``false``. If set to ``true`` the name of the starter class (``FeatureOne.java``, ``FeatureTwo.java``) will be appended to all feature paths. The implementation of the starter classes can be simplified to:

```
package apackage;

@RunWith(Cucumber.class)
@Cucumber.Options(appendStarterClassToFeaturePaths=true)
public static class FeatureOne{
}
```
In this case only FeatureOne.feature will be executed instead of all features in the package ``apackage``

Gain:
* less duplication of the feature file name
* the package of the the feature file does not have to be duplicated (it is taken from the starter class)
* less code to write
* all the starter classes look the same (except for there name)

Changing behaviour:
The default feature path that is generated if no ``Cucumber.Options`` annotation is present or no ``features`` argument is specified now ends with a trailing ``/``.
For a starter in the package ``apackage/sub`` the default feature paths changes as follows:
* ´`classpath:apackage/sub`` (before)
* ´`classpath:apackage/sub/`` (now)

In my opinion this should not be a problem.