You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to review handler scopes, but I'm not sure the above example should be implemented as a Handler class - probably better as an ExcecutionListener which receives lifecycle events including start() and end() for the whole session. To do this we'd need to add a hook to specify a custom ExecutionListener, which we should really do anyway.
Have thought about this some more and we have decided to enhance scoping for Handler classes to support a feature scope (handler gets created once per feature, reused for scenario). We will also support initialization and destroy methods which are scoped by scenario/feature, so a feature-scoped handler can do some initialization and tear down for individual scenarios as well as feature start/end.
I think the ability to configure a process to be feature scoped would be a nice idea. To support this we can change the ProcessHandler to be feature scoped, and allow a process to be configured as 'feature' or 'scenario' - if scenario then a process will be shut down when the scenario ends, otherwise at the end of the feature.
We are also adding a special 'Feature-Start:" and "Feature-End:" section to the supported syntax - these are special scenarios which perform setup and tear down for a feature and would be a good place to start any feature-scoped processes.
For processes which need to start and stay running for a whole suite of tests, an ExecutionListener would still be the best place to do this, since we won't be supporting any kind of suite scoping, at least for now. We will add the ability to specify a custom ExecutionListener class in the next release.
The user might want a process to Process to run until all feature files are completed.
E.G. Launch a server, run all tests against it, stop server.
Add the ability to override scope = HandlerScope.MANAGED or scope = HandlerScope.UNMANAGED in the XXX-processes.properties.
The text was updated successfully, but these errors were encountered: