Behavior of ScenarioInitializer when enable concurrency

[nvcnvn]

func InitializeScenario(sc *godog.ScenarioContext) {
	sc.Before(func(ctx context.Context, sc *godog.Scenario) (context.Context, error) {
		Godogs = 0 // clean the state before every scenario

		return ctx, nil
	})

	sc.Step(`^there are (\d+) godogs$`, thereAreGodogs)
	sc.Step(`^I eat (\d+)$`, iEat)
	sc.Step(`^there should be (\d+) remaining$`, thereShouldBeRemaining)
}

Will this function called repeatedly for every goroutine? I add some dummy logs and it seem yes.
I think this hurting performance too much when you have a lot of step (we have 1000 steps).
Should it be on Suite level instead?

[vearutop]

I think it does not matter if the concurrency is enabled or not, scenario initializer runs for every scenario.

This is an interesting idea, in many cases hooks and steps should be same for all scenario and indeed reusing them from suite can be a nice optimization.

Let me try a quick prototype.

[vearutop]

Please try go get -u github.com/cucumber/godog@suite-level-hooks in your project.
And then change your init from something like

		ScenarioInitializer: func(s *godog.ScenarioContext) {
			local.RegisterSteps(s)
		},

to something like

		TestSuiteInitializer: func(suiteContext *godog.TestSuiteContext) {
			local.RegisterSteps(suiteContext.ScenarioContext())
		},

Please share how much time does it take to run tests for both options.

[nvcnvn]

But will you consider to keep this sir? I guess if we don't have the regex complied and cached it will take alot more CPU.

[vearutop]

Yes, I think this change still makes sense as a way to organize layering of global and per-scenario hooks/steps, I'll create a pull request.

[vearutop]

Though, currently scenario initializer lacks any information (like feature or scenario name) to decide whether a step should be registered or not, so it is always working in "global" mode with regards to steps/hooks.

[vearutop]

@nvcnvn please try v0.12.4.

[nvcnvn]

Thank you sir!