Summary
The library ships RawContext (no step traits) and DrupalContext (17 curated traits), with nothing covering the full vocabulary. A consumer that wants broad coverage hand-maintains the entire list and re-edits it every time the library adds a trait.
Found while migrating the Vortex template to 4.x-dev as the first consumer (drevops/vortex#3159).
Details
4.x ships 57 step traits: 29 under Steps\Generic and 30 under Steps\Drupal, less the two HelperTraits, which are not vocabulary.
Vortex composes 54 of them. Its FeatureContext now carries 54 use statements plus 54 matching imports, and both lists have to be updated whenever a trait is added or renamed. The file is ~130 lines of which almost all is import and composition boilerplate.
DrupalContext cannot serve as the base, because it deliberately excludes WatchdogTrait, JavascriptTrait, AccessibilityTrait, DiagnosticsTrait and BigPipeTrait, all of which that consumer relies on: AccessibilityTrait backs a dedicated feature, WatchdogTrait's PHP-error check is load-bearing (the project's @error tag exists to opt out of it), and DiagnosticsTrait supplies the failure diagnostics block that makes CI output actionable. Extending DrupalContext and adding the remaining 37 traits back is possible but expresses "essentially everything" as "a curated subset, plus most of the rest".
Suggested direction
A FullContext, or an AllStepsTrait that composes every step trait, so the full-vocabulary case is a single line.
The usual objection is that it pulls in traits which can fail a scenario for a reason it did not ask about. The existing @behat-steps-skip:NAME tags already answer that: a project can disable any hook by method or by trait, per scenario or per feature.
Related
DrupalContext's exclusions are documented only in its docblock. A consumer who extends it gets no signal at the call site that, for example, a logged PHP error will no longer fail their build. Whatever shape the full-vocabulary option takes, naming the tiers so the difference is visible where the class is used would help.
Summary
The library ships
RawContext(no step traits) andDrupalContext(17 curated traits), with nothing covering the full vocabulary. A consumer that wants broad coverage hand-maintains the entire list and re-edits it every time the library adds a trait.Found while migrating the Vortex template to
4.x-devas the first consumer (drevops/vortex#3159).Details
4.x ships 57 step traits: 29 under
Steps\Genericand 30 underSteps\Drupal, less the twoHelperTraits, which are not vocabulary.Vortex composes 54 of them. Its
FeatureContextnow carries 54usestatements plus 54 matching imports, and both lists have to be updated whenever a trait is added or renamed. The file is ~130 lines of which almost all is import and composition boilerplate.DrupalContextcannot serve as the base, because it deliberately excludesWatchdogTrait,JavascriptTrait,AccessibilityTrait,DiagnosticsTraitandBigPipeTrait, all of which that consumer relies on:AccessibilityTraitbacks a dedicated feature,WatchdogTrait's PHP-error check is load-bearing (the project's@errortag exists to opt out of it), andDiagnosticsTraitsupplies the failure diagnostics block that makes CI output actionable. ExtendingDrupalContextand adding the remaining 37 traits back is possible but expresses "essentially everything" as "a curated subset, plus most of the rest".Suggested direction
A
FullContext, or anAllStepsTraitthat composes every step trait, so the full-vocabulary case is a single line.The usual objection is that it pulls in traits which can fail a scenario for a reason it did not ask about. The existing
@behat-steps-skip:NAMEtags already answer that: a project can disable any hook by method or by trait, per scenario or per feature.Related
DrupalContext's exclusions are documented only in its docblock. A consumer who extends it gets no signal at the call site that, for example, a logged PHP error will no longer fail their build. Whatever shape the full-vocabulary option takes, naming the tiers so the difference is visible where the class is used would help.