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] Add StepDefinedEvent #1634

Merged
merged 7 commits into from
May 30, 2019
Merged

[Core] Add StepDefinedEvent #1634

merged 7 commits into from
May 30, 2019

Conversation

timtebeek
Copy link
Contributor

Summary

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

How Has This Been Tested?

Not yet; Change seems small.

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).

Checklist:

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

@coveralls
Copy link

coveralls commented May 21, 2019

Coverage Status

Coverage increased (+0.005%) to 85.95% when pulling 3776a75 on timtebeek:step-defined-event into 75083d2 on cucumber:master.

Copy link
Contributor

@mpkorstanje mpkorstanje left a comment

Choose a reason for hiding this comment

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

Looks good. Bit light on the tests so far.

We do have a memory leak. Lambda step definitions internally have a reference to their closure via Java8StepDefinition.body. Normally this would be GC'd when the world is disposed of. However because we now push these step definitions onto the event bus this is no longer guaranteed. For instance, the canonical order event bus will hold on to all of them.

Ideally when removing the scenario scoped step definitions from the glue, we also remove their reference to the world.

It would be okay to add extra methods to StepDefinition, the interface is not part of the public API, but I would prefer deprecating isScenarioScoped in favor of an ScenarioScoped interface that implements a disposeScenarioScope method.

@timtebeek
Copy link
Contributor Author

Hmm; trying to see if I understand you correctly; You want to (for instance) add a disposeScenarioScope method in Java8StepDefinition which is called in Glue.removeScenariosScopedStepDefinitions(Map<String, StepDefinition>) ? And have that method assign null to the body field to remove the reference?

I'll be off for a few days, so will only be able to pick this up on the weekend..

@timtebeek
Copy link
Contributor Author

As for the test coverage; Agree it's "parse". Functionally the only new line is: bus.send(new StepDefinedEvent(bus.getTime(), bus.getTimeMillis(), stepDefinition));, but I didn't think it sensible to call it in Glue and verify that it's called in GlueTest. We've both seen waaay too much of that test pattern applied in our shared working history. ;)

@mpkorstanje
Copy link
Contributor

I was thinking of an integration test that creates a backend with 2 steps. Then run two scenarios with those two steps and check that we see 3 events emitted. There is utility class that makes it relatively easy to setup.

But I'll have to check.

Hmm; trying to see if I understand you correctly; You want to (for instance) add a disposeScenarioScope method in Java8StepDefinition which is called in Glue.removeScenariosScopedStepDefinitions(Map<String, StepDefinition>) ? And have that method assign null to the body field to remove the reference?

Exactly.

@mpkorstanje
Copy link
Contributor

mpkorstanje commented May 23, 2019

For testing this functionality you can find some examples in RuntimeTest. Adding an extra test there should be fine. I reckon something like this should do, it's a bit messy but should serve to illustrate the point.

        final CucumberFeature feature = feature("test.feature", "" +
            "Feature: feature name\n" +
            "  Scenario: scenario name\n" +
            "    When s\n");

        Plugin plugin = new ConcurrentEventListener() {
            @Override
            public void setEventPublisher(EventPublisher publisher) {
                // Capture some events here.                
            }
        };
        ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
        final Backend mock = new Backend() {
            
            @Override
            public void loadGlue(Glue glue, List<URI> gluePaths) {
                // Register some regular glue here        
            }

            @Override
            public void buildWorld() {
                // Register some scenario scoped glue here.
            }

            @Override
            public void disposeWorld() {

            }

            @Override
            public List<String> getSnippet(PickleStep step, String keyword, FunctionNameGenerator functionNameGenerator) {
                return emptyList();
            }
        };

        BackendSupplier backendSupplier = new BackendSupplier() {
            @Override
            public Collection<? extends Backend> get() {
                return singletonList(mock);
            }
        };
        FeatureSupplier featureSupplier = new FeatureSupplier() {
            @Override
            public List<CucumberFeature> get() {
                return singletonList(feature);
            }
        };
        Runtime.builder()
            .withBackendSupplier(backendSupplier)
            .withAdditionalPlugins(plugin)
            .withResourceLoader(new ClasspathResourceLoader(classLoader))
            .withEventBus(new TimeServiceEventBus(new TimeServiceStub(0)))
            .withFeatureSupplier(featureSupplier)
            .build()
            .run();
           // Check if the plugin captured the expected events here.

@timtebeek
Copy link
Contributor Author

@mpkorstanje Thanks for the hint on testing. I'm still having some trouble filling in the blank here:
public void buildWorld() { // Register some scenario scoped glue here.
The only examples of registering Lambda based steps I see are in the Java/Java8 modules; the approach there is hard to replicate in core due to missing classes. Any suggestions there?

I've added ScenarioScoped changes in 81f2c98 , I hope that's what you intended!

@mpkorstanje
Copy link
Contributor

A mocked step definition will do. As long as it isScenarioScoped returns true.

@timtebeek
Copy link
Contributor Author

Hmm; Looked into it again, but really stuck on the new Backend() { ... } details; Just too unfamiliar with the (test) internals I suppose. Would love to see this work; but I'm lost as to how.

@mpkorstanje
Copy link
Contributor

I've pushed a commit. It's a bit of a hack job but should get the point across.

@mpkorstanje
Copy link
Contributor

I should look into making some proper test implementations of the components I just mocked.

@timtebeek
Copy link
Contributor Author

Awesome, thanks! Had been eyeing the TestBackendSupplier, but wouldn't have worked out I'd need anything like MockedScenarioScopedStepDefinition or MockedStepDefinition on my own.. thanks a lot!
Anything else we need to cross off before we can consider a merge?

@mpkorstanje
Copy link
Contributor

Its good as is. But I am going to try and sneak in a redactor or two. There is an emerging pattern here that calls for some reusable test components.

You know the ratchet mechanism bring and keep quality up. May take a bit of time. It's been busy since we last spoke. There is less time for OSS now.

@timtebeek
Copy link
Contributor Author

Ok thanks for helping out; If I can help in any way let me know; all the best there! Miss working together in Amsterdam.. :)

@mpkorstanje mpkorstanje changed the title Add StepDefinedEvent to replace StepDefinitionReporter for Lamdba steps [Core] Add StepDefinedEvent May 30, 2019
@mpkorstanje mpkorstanje merged commit f172c4f into cucumber:master May 30, 2019
@aslakhellesoy
Copy link
Contributor

Hi @timtebeek,

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

Cheers. No worries!

mpkorstanje added a commit that referenced this pull request May 30, 2019
The StepDefinitionReporter interface was deprecated in v4 #1634.

Closes #1635
@timtebeek
Copy link
Contributor Author

Awesome, great to see this merged! I'll update my unused steps plugin blog post to include these Java 8 steps. Should I start a PR to contribute that as well? It's small, has no dependencies and could be useful plus serve as example.

@mpkorstanje
Copy link
Contributor

mpkorstanje commented Jun 1, 2019

Would not mind seeing it. Though the json format is problematic. Almost impossible to evolve on. Perhaps we can have a look at that.

mpkorstanje pushed a commit that referenced this pull request Jun 4, 2019
## 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.
@lock
Copy link

lock bot commented Jun 24, 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants