Deprecate subcontexts

[jhedstrom]

I've been thinking about ways to resolve #487 and one thought is to re-work how sub-context discovery happens, or since it isn't a much used feature, deprecate it in favor of just manually specifying where to search for additional steps (this is already supported).

[jonathanjfshaw]

I've not dug into subcontext discovery but I know a bit about plugin discovery. How that works is that the plugin files are found based on a path, and then plugins from uninstalled modules are discarded.

Knowing what's installed or not does require a Drupal bootstrap (because you need the configuration) but maybe path based discovery doesn't? And maybe we don't mind loading contexts from uninstalled modules that are still present in the codebase, it's not ideal but not a disaster.

[pfrenssen]

I would prefer to keep them if possible. Or at least if it needs to be reworked keep the principle of automatically making a set of step definitions available as soon as a module is enabled. I think it is very handy and we use this extensively in our custom modules.

[pfrenssen]

I have changed my mind on this matter. I've been thinking about it the last couple of months and I've grown convinced that modules should in fact NOT provide step definitions that activated automatically when the module is enabled.

A module can only provide step definitions that use the business language of the module authors. For example if the Taxonomy module would provide step definitions then it will be natural for them to use business language that uses words like "taxonomy", "vocabulary" etc. This won't necessarily match the business language of a project's client: they might call them "hashtags" or "labels".

I think this problem makes the usefulness of subcontexts very limited in general. I am using subcontexts heavily in my custom project, but we could just as well use normal context classes, and list them in the behat.yml manually.

I think the best practice for a module to provide Behat integration would be to:

• Provide a trait with helper methods that make it easy for end users to develop their own step definitions.
• Provide a Context class with example implementations that end users can use as inspiration, or extend to easily modify the step definitions to their own use cases. Developers could even decide to directly add the example context in their behat.yml file they desire.
• Provide some example scenarios that can be run to prove that the Behat code works as expected.

Deprecating subcontexts is fine for me.