Replies: 6 comments
-
I am not familiar with Cucumber and the target of shellspec is shell script unit testing (I mean a shell function test). I am not sure if the syntax only comparison makes sense but... Shellspec syntax is compatible with shell scripts. Therefore not as flexible syntax as Cucumbers that translate with parsing regexp. Some syntaxes are similar and others are not. For example, shellspec has I am just implements for shell script unit testing, so it difficult to compare. |
Beta Was this translation helpful? Give feedback.
-
Thank you again for all the work that has gone into Shellspec and for making it open source. We think that it would be great if Shellspec adopted the aim of Gherkin compatibility. If not fully Gherkin compatible by default, at least provides a Gherkin compatibility "mode" set via configuration? @ko1nksm, you are correct that the Gherkin spec envisions that users have flexibility to write their own steps. IMO the constraint of predefined steps is fine - it is much more likely that a team will implement in Python, Go, Rust, etc etc some functionality that has been spiked in a shell script, than to port an application the other way around. Please note that such Gherkin compatibility would not be in terms of the Cucumber implementation choices (e.g step files) but in terms of the 'feature' file content such as: Given <shellspec specifics here>:
| name | email | twitter |
| Aslak | aslak@cucumber.io | @aslak_hellesoy |
| Julien | julien@cucumber.io | @jbpros |
| Matt | matt@cucumber.io | @mattwynne | Specifically, Shellspec would not, by default or in compatibility mode, allow you to write a feature file that was incompatible with a Gherkin engine (in possession of the appropriate, Shellspec compatible, step definitions). This use case envisions feature files being shared among teams or programming languages. Use cases this would open up:
@mcandre if that doesn't sound crazy maybe change the title to refer to Gherkin rather than Cucumber? |
Beta Was this translation helpful? Give feedback.
-
Having just said that Gherkin would leave you free to stick with your implementation choices, I will now point to something that does affect how you implement things... Pre-existing translations (70) But, again, this is not required to be "one-way" Gherkin compatible, and might give an idea of how to handle the future question of translations. |
Beta Was this translation helpful? Give feedback.
-
A related set of features that you might find informative are the Aruba steps. One possibile course of action is to leave all the existing No doubt there could be some code re-use but I'm not that familiar with the code base. |
Beta Was this translation helpful? Give feedback.
-
Convert issue to a discussion |
Beta Was this translation helpful? Give feedback.
-
Not easily - although both are expectation-led, they're actually addressing 2 very different things - Cucumber (& Gherkin) are, by both intention & design, customer/consumer-facing and were designed to define behaviours in a structured & very abstract i.e. non-technical, manner that is typically employed in acceptance style test patterns that may be executable in nature; Whereas Shellspec is, like RSpec, very much a TDD language in as much it addresses very technical behaviours in a detailed manner and are far better aligned with and thus better employed in, the Unit & Component level testing patterns which are inevitably executable in nature. |
Beta Was this translation helpful? Give feedback.
-
How does shellspec syntax compare to Cucumber syntax?
Beta Was this translation helpful? Give feedback.
All reactions