This slightly relaxes the language for the SuiteContext matchers, so
that whether one starts the step with “a …” or not it will match either
way.
(It also eliminates one duplicate matcher that essentially did the same
thing without a regex.)
This allows it to be easily re-used in other libraries to do
meta-testing on their own godog features/steps.
At some point it may make sense to migrate this entirely to a
sub-package of godog, however that would require a larger
re-architecting of the project structure to avoid circular dependencies
(e.g. `import cycle not allowed`).
Best of both worlds, this allows for a single int64 value in the
Options struct, but at the same time we can do `—random` from command
line with no args and have a default value Chosen.
allows for setting randomization with flags, but also modifies the
Options struct to now have two separate values
Overall this relates in a much more understandable UI from a user
perspective, since the normal case for randomization will be a user
just saying “run these out of order please” — and in a rare case they
may wish to additionally supply a seed to try to reproduce an older run
to trigger the same error condition.
while global rand is concurrent safe, since each suite is handling
picking scenario order on it’s own, if running features under
concurrency we cannot guarantee the order Features will execute under,
therefore we have each suite initialize its own randomness Source with
the initial seed, such that their random order selection within a
Feature should always be deterministic when given a specific seed.
This allows for us to propagate the seed value around, and not have to
have two different values in Options when we want to allow
specification of seed. It does introduce some “magic values”, but the
document them in the Options struct docstrings.
