forked from cucumber/cucumber-jvm
-
Notifications
You must be signed in to change notification settings - Fork 0
[pull] master from cucumber:master #2
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
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[Core] Refactor Runtime Extracting: Backend creation, Glue creation, Runner creation Feature compilation from the runtime allows Tests on runners to skip the creation of Runtime Makes extracting Filter provider(#1352) and Feature provider(#1366) easier. Other runtimes such as JUnit and TestNg to skip the creation of the runtime --parallel (#1357), junit 5 (#1149) and pickle runner support. Clarifies the execution loop of Cucumber
This feature is the java implementation of --wip of Cucumber-Ruby. Implements strict in combination with according to the spec: Spec: | --wip | --no-wip | | --strict | --no-strict | --strict | --no-strict | PASSED | fail | fail | pass | pass | SKIPPED | pass | pass | pass | pass | PENDING | pass | pass | fail | pass | UNDEFINED | pass | pass | fail | pass | AMBIGUOUS | pass | pass | fail | fail | FAILED | pass | pass | fail | fail | Closes: #1381
Cucumber-jvm is using some library features that were introduced in Java 7. Setting the compilation explicitly to Java 7 should avoid any unexpected surprises.
[Examples] Simplify Gradle example
…#923) [Weld] Document the need for a beans.xml per source root
Add documentation for spring object factory
[OSGi] Remove OSGi
* Extract Android to separate project * Move Travis config for Android
Adds supports for parallel execution of pickles to cucumber-jvm # Added --threads argument to runtime options Allows users of the CLI to specify the (max) number of threads to be used to run the tests. TestNG/JUnit users should consult their documentation on how to run JUnit/TestNG in parallel. Note that JUnit will only run features in parallel, not scenarios. # Concurrent Events During parallel executing events from the execution of different pickles may interleave. To avoid breaking existing Formatters, these will now receive all test events after the run is complete. Because we are unable to infer whether JUnit/TestNG run in parallel the assumption is that they are and their formatter will always get all events after the run. Formatters that can handle concurrent events can events in real time by implementing the ConcurrentEventListener. # New formatter introduced TimelineFormatter Which produces reports using vsjis.org timeline to highlight which feature was run on which Thread and when.
Before it was using the standard threadfactory, which was naming threads like `pool-x-thread-y`. Now it is `cucumber-runner-y-thread-x`. This better for logging to see which threads belong to cucumber and which are unrelated background
Backport of commit a03dd01 so it is possible to use ServciceLoader for ObjectFactory with 4.x
The existing parallel implementation was rather naive. It assumed that the execution of a pickle would be exception free and it assumed that it would not be interrupted. These assumptions turn out to be unreasonable: See #1628. By logging any exceptions thrown and re-throwing them collectively we address the first aspect and when interrupted all pickle executions should be interrupted as well. At this point we return control immediately.
CDI 2 has a dedicated API to manage a container. This enables dependency injection for any CDI2 implementation.
Adds a `StepDefinedEvent` to replace the `StepDefinitionReporter` plugin interface. ## Details Publish an event from `Glue.addStepDefinition`, as `Runner.reportStepDefinitions` is called before step definition classes are instantiated, which fails to pick up on lambda based steps. ## Motivation and Context Provide an event to listen for steps being registered, so all steps registrations are available, instead of only the annotation based step definitions. #1633
## Summary Adds a plugin to find and report on unused steps. ## Details As discussed in #1634 it uses the new StepDefinedEvent to locate all registered steps, and prints a summary of unused steps to the argument file. ## Motivation and Context Allows to easily find unused steps, which might be indicative of removed functionality or missed test coverage.
Fixed failure to parse UTF-8-BOM encoded feature file. Fixes: #1639
…rce (#1656) Fixes #1515. Ensures non-ConcurrentEventListener plugins get events immediately when running on a single thread, rather than delayed until all tests are run. As discussed in #1515 the pretty text output for cli/junit/testNg is also delayed for users running on a single thread from their IDE or commandline. This small change restores immediate text output when running on a single thread, only delaying when multiple threads are involved. A better fix would be an overhaul of the PrettyFormatter, but that's considerably more work, whereas this would fix a lot of the same use cases.
Summary Allows scenarios to be executed in random or reverse order. Custom execution orders can also be created. Details All scenarios can be run in random order. `java <classpath> cucumber.api.cli.Main --order random -g <glue path> <feature file path>` The number of scenarios to be run in random can also be mentioned. `java <classpath> cucumber.api.cli.Main --order random --count <number> -g <glue> <feature file>` All scenarios can be run in reverse order. `java <classpath> cucumber.api.cli.Main --order reverse -g <glue path> <feature file path>` Custom orders can be created by implementing the PickleOrder interface in the `cucumber.runtime.order` package.
pull bot
pushed a commit
that referenced
this pull request
Jul 31, 2019
Refactors the Env property sources to allow different property source hierarchy for each runner. These ordering having been chosen such that sensible default values can read from file or 'hardcoded' configuration can be overridden by environment properties, system properties or CLI arguments. CLI property source order: 1 Command line 2 System properties 3 Environment variables 4 cucumber.properties file JUnit and TestNG property source order: 1 System properties 2 Environment variables 3 ``@CucumberOptions` 4 cucumber.properties file Old situation: JUnit, TestNG, and CLI property source order: 1. System properties 2. Environment variables 3. cucumber.properties file 4. CLI arguments or `@CucumberOptions` Additionally in the old situation the commandline arguments in #1,#2,# 3would replace rather then be merged with each other. The result would be merged with #4. This was somewhat confusing.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]