Upstream status

[taqtiqa-mark]

Hi, Thanks for all your effort on the the Julia implementation of Cucumber. I'm trying to get a feel for the state of play. It does appear that this is the only implementation of Cucumber/Gherkin in the Julia space.

If you'll excuse the presumption, I've opened an issue upstream to find out if Cucumber Ltd have any plans regarding Julia, and to get their feedback on how to best to proceed, from their PoV. This issue is at cucumber/cucumber#407.

I'd appreciate any of your thoughts and plans you'd like to share. In particular your view of how feature complete the items are that I've listed, and any items that you think should be added or removed from that list.

[erikedin]

Hi!

I've left a comment explaining my position in the Cucumber repo. In short, my package isn't actually derived from Cucumber directly, and it's not appropriate for inclusion in Cucumber. I intend my package to be a pure Julia implementation, so it can be used without any external dependencies.

I may be able to shed some light on what would be required to create a Cucumber binding to Julia, so I'll leave this issue open for as long as you want, and we can discuss it here.

[taqtiqa-mark]

Hi, Thanks for sharing your thoughts. I've read your response upstream. I also had a pure Julia implementation in mind, rather than the wire protocol. I'm sure I'll be referencing your Julia code frequently.

Can you elaborate on the 'external dependencies' you're avoiding, e.g. do you mean anything outside of Julia's Base? Probably related... by

it could be executed as part of the normal tests for Julia code

do you mean you're targeting inclusion of this in Base.Test and Base.runtests, i.e. is this targeted for a specific Julia release?

not meant to be a Cucumber replacement or a Julia implementation of Cucumber

I suppose there are two issues entangled here. The Gherkin *.feature files (grammar?) and the Cucumber functionality, i.e the interpreter of the Gherkin files. Are you able to share the parts of Gherkin you won't be implementing, This would be useful to know to indicate how much of their *.feature files people can expect to port without change and how much they can expect to have to edit. Or is it some of the behaviors of Cucumber, the interpreter, you'll omit?

It's been a few years since I had my head in Cucumber's world, so I've possible got the wrong end of the stick. Appreciate any insight you can share.

[erikedin]

I am not depending on anything outside of Base, if I recall correctly, simply to keep it small and self contained. By 'external dependencies' I was mostly thinking of running external software such as Cucumber over a wire protocol.

By running as part of normal tests, I meant that it should be runnable as part of doing julia test/runtests.jl, for unit tests.

I am not intending to include this package in any other upstream package at all. I fully intend this to remain as an independent package maintained by myself.

For Gherkin, I believe I will support all of the grammar. However, I have yet to find a formal reference for it, so there will be inconsistencies, I imagine, even if they are small.

When it comes to Cucumber functionality, I imagine I will support much less than they do. Unfortunately, I don't have a good idea of the extent of Cucumbers functionality, so I cannot give you a solid idea of what parts of their functionality I intend to implement and not. The general roadmap for my package is that you will be able to write step definitions for Gherkin files, and execute them. Regular expressions and tags will be implemented, but possibly not to the same extent as Cucumber. You will be able to produce reports from the results, but I will focus on a plug-in architecture for such report generators, rather than support many formats myself.

I believe that the weakest points of my implementation will be integration with other software.

[taqtiqa-mark]

Thanks @erikedin appreciate you taking the time to respond.

I am not intending to include this package in any other upstream package at all.

OK. Not sure how linked in to the dev network you are. My experience is this type of framework is essential for any complex project.
Given Gall's Law, that pretty much means every project.

Has anyone proposed this sort of functionality be included in Base?

For Gherkin, I believe I will support all of the grammar. However, I have yet to find a formal reference for it,

See Aslak's reference here

Unfortunately, I don't have a good idea of the extent of Cucumbers functionality

See here for some feature files. A find for feature files through the upstream repo should be a quick way to discover the state of play.

Are you open to PR adding the feature files and marking them 'pending' or wip?

That way the current state of play will become clearer, and the remaining tasks will be predefined. The benefit is that features that aren't supported can be placed in a unsuppported sub-folder, a link to this gives users a reference point when they are looking at the gazillion blog entries describing Cucumber/Gherkin BDD use best practices, idioms etc.

It seems upstream are targeting a golang parser, if it works out. So implementing a gherkin parser seems unavoidable.

[erikedin]

Hi Mark,

This package is of course available in Julias package manager. I'm sorry if that was unclear. It's easy to include it in any Julia project, and so this project does not need to be merged into any other upstream project. Julias standard library Base is not an appropriate place for it. Base only contains things that can reasonably be thought to be common to all or most Julia projects, and a BDD framework like this would not be a good fit.

I had a look at the feature files, and I already have support for all the important parts of Gherkin. Some minor things like emojis and languages are not implemented in my project yet, but they are also not critical. So, these feature files are of little value at the moment.

[taqtiqa-mark]

Thanks @erikedin appreciate you taking the time to respond. Closing as I think everything has been addressed.