A way forward for Behat #1383
ciaranmcnulty
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
As a volunteer-maintained project we have lost a lot of momentum over the last couple of years, which is not great for the large community that uses it.
I'm proposing this not as a 'master plan' but as a way to go in the absence of any other plan, and as a list of things I would maybe be interested enough to do :)
These steps are roughly in order or operations.
Properly deprecate existing Behat org extensions
These aren't marked as abandoned etc., they should be. Extensions should be something that happens in the community, outside the Behat org.
Make a new Behat 4.0 branch to capture Backwards Compatibility (BC) breaks
We've had this idea of maintaining a lot of BC for a long time now, but it's not sustainable. A lot of it was driven by willingness to go the extra yard to maintain that BC (Konstantin even did talks about it). I don't consider that achievable with current resource, we're not Symfony-sized.
We should support 3.0 for a long time, but maybe at current energy levels i.e. best-efforts bugfixing. It's been stable for a long time!
I wouldn't attach a specific timetable to a 4.0 release - just do it when it's ready.
Remove the amount of abstraction in Behat
The codebase is built in a highly abstracted way (including a whole test-framework abstraction TestWork), partly to support extreme BC. Abstractions that haven't proven useful in the last decade should be removed, including collapsing Testwork-namespaced stuff into Behat.
Integrate cucumber/gherkin
OK I wrote the PHP port of cucumber/gherkin, but part of the point of it is that the Cucumber org will help maintain it.
Behat 3 should have a (cli/config) flag that allows the cucumber parser to be used. Support will necessarily be slightly hacky - we'll need to map the cucumber AST to the Behat one (and flatten out Rules into being owned by the Feature).
Behat 4 can depend directly upon the 'pickles' concept in the library rather than the AST, and in fact should hugely simplify Behat by largely removing concepts like Backgrounds and Scenario Outlines from the runner.
Port and integrate Cucumber Expressions
Cucumber Expressions offer a consistent expression-matching experience across implementations (they were partially inspired by our turnip expressions but are not compatible).
We can port the library and offer it in Behat 3 in parallel to Turnip. If we make it Annotation-only we can make it easy for users to switch which set of expressions they're using by swapping the annotation namespace.
Behat 4 could only allow Cucumber Expressions, or at least only allow annotation-based matches
Again, a point here is to move some maintenance to a different org!
Integrate the Cucumber HTML Formatter
This is a pretty nice HTML formatter, much better than we've produced. To integrate it the runner would only need to emit the right message stream and bundle the javascript+HTML
Offer an integration with PHPUnit
This doesn't really need to be a Behat thing, but I think it'll happen somewhere. If we have a cucumber/gherkin and cucumber expressions libraries out there it makes it easy to 'build your own Behat' anyway.
It makes sense to have some Trait that adds these capabilities to PHPUnit tests (and can slip into something like a Symfony\Panther test using all that tooling without replicating it)
Beta Was this translation helpful? Give feedback.
All reactions