Closed alexanderjeurissen closed 3 years ago
That is an almost certain "no" from me. It was quite intentional to keep cuke_modeler
independent of what implementation of Cucumber a user has. Bringing step definitions back into the mix would couple things to the Ruby implementation of Cucumber.
That being said, I could see an extension gem (named cuke_modeler-stepdefs
or something like that) being made. That way extra stuff is not being dumped on a user by default but the extra stuff could still be easily added to a project and play well with the rest of the cuke_modeler
family of gems. If enough non-Ruby users started using cuke_modeler
for their projects, there could even be cuke_modeler-stepdefs-javascript
, etc. gems made.
As far as where in the model tree step defs should live, I don't know. I think that back in the analytics gem they lived in an essentially separate World
module because, well, they don't really have any relation to anything else. They are just kind of available for any test to use at runtime. So sticking them in anywhere in the model tree seems kind of arbitrary aside from perhaps, as you suggested, under whatever directory they happened to be defined in. Buuuuuuuut, even then that could get cumbersome quickly if people had their steps defined in many far flung places. Having a central place for code to look (e.g. a World
model) is convenient and if a user wants to know where the step definition came from then they could check the StepDefinition
model for its path.
Thanks for elaborating.
I like the idea of having other gems or classes that act like addons to the cukemodeler gem.
I'll give this some more thought.
cuke_modeler
is the successor ofcuke_analytics
.In the readme of
cuke_analytics
you state as much, with the side-note that the only reason to use the former is for itsstep_definition
support.I think it would be beneficial if one could use a single gem for all their cucumber modeling needs so we can 💀
cuke_analytics
for good.Would you be open for a PR that adds support for step definitions ?
My preliminary thinking is that as a first step
step_definitions
would be a child of theDirectory
class. This would enable for adding basic linting for step definitions incuke_linter
.Given that cucumber steps by default live in subdirectory of the base feature directory, this should work in most standard setups. If not, getting your hand on modeled step_definitions is only one
Directory.new(setp_definition_path)
away.WDYT ?