Skip to content

[pull] master from cucumber:master #56

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 541 commits into
base: master
Choose a base branch
from
Open

Conversation

pull[bot]
Copy link

@pull pull bot commented Aug 2, 2019

See Commits and Changes for more details.


Created by pull[bot]. Want to support this open source service? Please star it : )

mpkorstanje and others added 10 commits February 6, 2020 23:19
The Cucumber CLI is rather complex to use. To work correctly it needs both
a `--glue` parameter in the form of a package name and a location of a feature
file in form of a classpath uri or path. As a result people often configure
Cucumber incorrectly and are left wondering why their features or glue can not
be found.

This can be simplified as shown by the Cucumber Platform Engine which defaults
to the classpath root and the JUnit and TestNG runners which default to the
package of the runner class.

So it makes sense to do the same with the CLI.

Assuming the following project layout the CLI can discover and execute
all features without needing additional arguments.

```
├── pom.xml
├── src
│   ├── main
│   │   └── java
│   │       └── com/example/Application.java
│   └── test
│       ├── java
│       │   └── com/example/StepDefinitions.java
│       └── resources
│           └── com/example/example.feature
```

This can be done with a single maven command:

```
mvn exec:java                                  \
    -Dexec.classpathScope=test                 \
    -Dexec.mainClass=io.cucumber.core.cli.Main
```

Additional benefits can be found in the fact that IDEA often can't work out
which package should be used as glue and does not provide a default. The
Cucumber Eclipse plugin on the other hand always defaults to the class path
root.

Fixes: #1875
When scanning `path/to/com/` containing a resource named
`path/to/com/example/app/app.feature` the middle package `example/app` would be
rendered as `example.app` as the implementation would use
`determineSubpackageName` rather then `determineSubpackagePath`.

Fixes #1892
Features discovered by a single selector are sorted by Feature::getUri. When
multiple discovery selectors are used feature order is no longer well defined.

Effectively when multiple selectors are used, in the current implementation the
features will be sorted by the discovery selector that first discovered it,
then by Feature::getURI.
@pull pull bot added the merge-conflict Resolve conflicts manually label Feb 19, 2020
mpkorstanje and others added 14 commits February 20, 2020 13:59
…#1899)

The JUnit Platform supports skipping tests. For example in JUnit Jupiter a
test can be annotated with `@Disabled`. This test will be marked as skipped.

Cucumber scenarios do not have annotations nor is there any support to disable
specific scenarios. A typical work around with Cucumber JUnit 4 integration was
to set a permanent tag filter for `not @Disabled` in `@CucumberOptions`.

This wasn't possible with the JUnit Platform yet. By adding the
`cucumber.filter.tags` property it becomes possible to recreate JUnit Jupiter's
`@Disabled` functionality.
By setting `cucumber.filter.tags=not @Disabled` property any scenarios tagged
with `@Disabled` will be skipped.

Note that contrary to JUnit 4 skipped scenarios are not removed from the test
hierarchy. This is entirely intentional and a result of the way the JUnit
Platform supports skipping tests.
The `cucumber-jvm` parent pom included `jackson-databind` in its dependency
management section. Because this is a test only dependency it was marked as
test scoped.

While not intended to function as a bill of materials people were and perhaps
still are using `cucumber-jvm` in this fashion. Removing `jackson-databind`
from the dependency management ensures that `cucumber-jvm` only manages
cucumber and test related dependencies.

While not safe, this does provide a modicum of safety.
…1905)

When neither a glue class with a spring context configuration could be found
nor a `cucumber.xml` file exists `cucumber-spring` will fall back to a
`GenericApplicationContext` to facilitate dependency injection.

The current implementation tries to reuse this application context between
scenarios. This requires refreshing the context which can only be done once.
So it's not possible to reuse the `GenericApplicationContext` and a new one
should be created for each scenario.
Parsing the feature below results in an NPE because Gherkin v5 uses the location
of the first cell as the location of the table. Because there is no cell, there
is no location. In this case we fall back to using the line of the step + 1.

```
Feature: Empty table

  Scenario: This is valid Gherkin
    Given an empty list
      |
```
renovate bot and others added 29 commits June 9, 2020 00:12
The `Stats` would use `Locale.getDefault()` resulting in different test
output by the `DefaultSummaryPrinter` when used in a locale with a
different decimal separator (e.g: France). Fixing the locale to US in
the test should avoid this problem.

Closes: #2010
Javax migrated to jakarta namespace.
To support this we implement the cdi-jakarta module as a fork of the cdi2 module.

Fixes: #1996
Updated the TagPredicate and the CoreHookDefinition to catch
TagExpressionException and add information from the relevant classes to the
exception message which is then wrapped in a RuntimeException and rethrown.
The rethrow as a RuntimeException is due to the fact that the constructor for
TagExpressionParser is package scope only and is not available in other
packages.

Fixes #1976.
Co-authored-by: Renovate Bot <bot@renovateapp.com>
It was not clear that the `cucumber-junit-platform-engine` takes it properties in a different manner.
Parameter names were taken directly form the parameter names used in the
cucumber expression. By passing these through the identifier generator
we can ensure that these are valid identifiers.

To reflect this new usage the `FunctionNameGenerator` was renamed to
`IdentifierGenerator`. The identifier generator uses a strategy pattern to join
words into method and parameter names.

Parameter names are always generated using the camel case strategy. While
long sentence like method names may be more readable in snake case, it is
expected that people will still want to follow the java conventions for
parameters.

To avoid issues where a parameter name were already in camel case or underscore
case sentences are also split on camel case and underscores (in addition to
whitespace). This also required using all lower case in the `UnderscoreJoiner`
which has since been renamed to `SnakeCaseJoiner`.

Fixes: #2028
@mpkorstanje mpkorstanje deleted the master branch September 25, 2020 21:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⤵️ pull merge-conflict Resolve conflicts manually
Projects
None yet
Development

Successfully merging this pull request may close these issues.