Skip to content
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

[Core] Parallel cukes #1389

Merged
merged 103 commits into from
Jul 6, 2018
Merged

[Core] Parallel cukes #1389

merged 103 commits into from
Jul 6, 2018

Conversation

boaty82
Copy link
Contributor

@boaty82 boaty82 commented Jun 9, 2018

Notice

This PR replaces Parallel support #1357 and relies on Refactor Runtime #1367

Outline

I’ve previously used another implementation to deliver parallel execution of cucumber tests, however it basically wrapped up the creation and execution of Runtime’s, followed by the need to merge the multiple JSON/HTML etc reports that followed.

I reviewed the current implementation and also took note of comments in Support concurrent executions of scenarios also I perused all tickets related to running in parallel cukes for other insights

Main changes

Added --threads argument to runtime options

Allows users to specify the (max) number of threads to be used to run the tests

The actual number of threads used will be the smaller of the given --threads value and the number of features to be executed

Tests are placed into a Queue and consumed by each thread when needed, resulting in a more performant usage of the threads & less deterministic order of Features being run

New formatter introduced TimelineFormatter

Which produces reports using vsjis.org timeline to highlight which feature was run on which Thread and when.
Note: the resources (js, html etc) are currently within cucumber-core if the PR is accepted then I’d imagine these would have to be moved out into its own project, similarly to cucumber-html.
timelineformatter
example.zip

Types of changes

  • Bug fix (non-breaking change which fixes an issue).
  • New feature (non-breaking change which adds functionality).
  • Breaking change (fix or feature that would cause existing functionality to not work as expected).
    - Runtime constructor now private Runtime.Builder introduce to hide away boiler plate setup/instantiation code

Checklist:

  • I've added tests for my code.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.

@mpkorstanje
Copy link
Contributor

Preliminary release notes:

  1. Cucumber can be run in parallel. Use --threads fro the CLI or consult the documentation on how to run JUnit/TestNG in parallel.
  2. JUnit can now be run in parallel. Will only run Features in parallel (for now). Changing this to pickles will result in the loss of the outline.
  3. TestNg can now be run in parallel. Will run pickles in parallel.
  4. With the exception of the CLI Formatters will now receive all test events after the run is complete. When running from the CLI formatters will receive all test events after the run is complete only when running in parallel.
  5. Implement concurrent event listener to receive events in real time, but keep in mind that TestCaseEvents may interleave.
  6. We have a new timeline formatter which looks pretty.

Anything I missed?

@mpkorstanje
Copy link
Contributor

I would like to update the examples with some configuration that makes them run in parallel but that can be done after merging.

@boaty82
Copy link
Contributor Author

boaty82 commented Jul 5, 2018

RE: Release notes. Nope can’t think of anything, other than the massive refactoring ;o)

@mpkorstanje mpkorstanje merged commit f840358 into cucumber:master Jul 6, 2018
@aslakhellesoy
Copy link
Contributor

Hi @boaty82,

Thanks for your making your first contribution to Cucumber, and welcome to the Cucumber committers team! You can now push directly to this repo and all other repos under the cucumber organization! 🍾

In return for this generous offer we hope you will:

  • ✅ Continue to use branches and pull requests. When someone on the core team approves a pull request (yours or someone else's), you're welcome to merge it yourself.
  • 💚 Commit to setting a good example by following and upholding our code of conduct in your interactions with other collaborators and users.
  • 💬 Join the community Slack channel to meet the rest of the team and make yourself at home.
  • ℹ️ Don't feel obliged to help, just do what you can if you have the time and the energy.
  • 🙋 Ask if you need anything. We're looking for feedback about how to make the project more welcoming, so please tell us!

On behalf of the Cucumber core team,
Aslak Hellesøy
Creator of Cucumber

@mpkorstanje
Copy link
Contributor

I've merged this a bit earlier then planned to unclog some stuff. Welcome aboard Boaty.

@aslakhellesoy
Copy link
Contributor

Very exciting stuff!!!!

@boaty82 if you haven't already, please have a look at the roadmap.

I think it would be great to extract the timeline formatter to a standalone command line program at some point, when Cucumber-JVM can report results as protobuf messages. That will make the formatter easier to maintain, but more importantly, it will allow any Cucumber implementation to use it.

@boaty82
Copy link
Contributor Author

boaty82 commented Jul 6, 2018

If you let me know what branch to work from etc then I’ll happily carry on contributing to this and other parts where and when I can help

@jdowneyEverest
Copy link

@boaty82 Thanks for your work on this!
I have a couple questions. How are the number of threads to be used determined? Does this only work when running with junit or testNG?

@boaty82
Copy link
Contributor Author

boaty82 commented Oct 11, 2018

@aslakhellesoy

I think it would be great to extract the timeline formatter to a standalone command line program at some point, when Cucumber-JVM can report results as protobuf messages. That will make the formatter easier to maintain, but more importantly, it will allow any Cucumber implementation to use it.

Does this still need doing? If so, I'll happily crack on with this in the next few days - just been too busy recently with work and managing to hurt myself 🤕

@aslakhellesoy
Copy link
Contributor

Does this still need doing?

Yes - we don't want any formatters to be implemented in Cucumber-{jvm,js,ruby,xxx}. As described in the roadmap, all formatters should be standalone command line programs (preferrably go) that can be used by all implementations using the message protocol.

@aslakhellesoy
Copy link
Contributor

Have a look at the dots-formatter to get an idea of a very simple implementation.

@boaty82
Copy link
Contributor Author

boaty82 commented Oct 16, 2018

Unless I am mistaken it looks like the data defined in messages protocol will need expanding to include the thread id the test ran within.

@mpkorstanje
Copy link
Contributor

Maybe call it executorId. The thread is an implementation detail.

@james-bjss
Copy link
Contributor

Unless I am mistaken it looks like the data defined in messages protocol will need expanding to include the thread id the test ran within.

Is this something that would be considered for the current events?

Use case:
I have been looking at Allure recently which has httpclient filters for capturing requests, these are correlated with the current executing step in it's formatter. Unfortunately it doesn't work with Cucumber4/parallel running as the formatter doesn't receive the events until after the test run.

If the thread(executorId) was available in the the event messages it should be possible to match these up after the run (or during if using a concurrent version of the formatter).

Happy to raise this in a new thread if this isn't the right place for this convo.

@mpkorstanje
Copy link
Contributor

It'd be better to raise a new thread for that.

@boaty82
Copy link
Contributor Author

boaty82 commented Oct 25, 2018

@aslakhellesoy I cannot get the dotsformatter to build, tried various things and all I get is

can't load package: package github.com/cucumber/cucumber-messages-go: no Go files in /Users/xxx/go/src/github.com/cucumber/cucumber-messages-go

for (CucumberFeature feature : features) {
for (final PickleEvent pickleEvent : compiler.compileFeature(feature)) {
if (filters.matchesFilters(pickleEvent)) {
executor.execute(new Runnable() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I see this correctly, that will simply swallow any exceptions thrown while executing a pickle - i.e it will log them, dispose the executor thread and then execute the next pickle in a new executor thread.
I have seen this behaviour because there's a bug in my ConcurrentEventListener. It doesn't make the cucumber run fail!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you make an issue for that? Ideally we catch all exceptions in the runner and fail the pickle.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #1628

@lock
Copy link

lock bot commented May 20, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

1 similar comment
@lock
Copy link

lock bot commented May 20, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators May 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants