<story><title>Robot Framework: generic open source automation framework</title><url>https://robotframework.org/</url></story><parent_chain><item><author>abracadabra_</author><text>I will never understand the reason for Cucumber to exist. As you say, it just introduces unnecessary complexity for no reason.&lt;p&gt;If you can&amp;#x27;t code, you shouldn&amp;#x27;t be writing automated tests. Most of the &amp;quot;benefits&amp;quot; of Cucumber can be gained by using a good reporting framework. I like to use Serenity as I love its reports.</text></item><item><author>lvncelot</author><text>I am less than lukewarm on those sort of &amp;quot;Natural-Language-Like&amp;quot; DSLs that seem to mostly come out of the QA space.&lt;p&gt;When I worked together with a QA team for automated testing, they used Cucumber, which uses Gherkin as an english-but-not-really DSL. Now the idea is obviously, that someone who doesn&amp;#x27;t know how to code can still describe and read test scenarios. But what ended up happening eventually is that I spent a lot of time writing code to support different Gherkin expressions, but then had to take over writing the Gherkin expressions as well, because even though Gherkin -looks- like english, it still behaves like a programming language. In the end, it would&amp;#x27;ve been much easier for me to just write the tests in a programming language from the start, instead of using an abstraction layer that turned out to serve no purpose.&lt;p&gt;What I took away from that frustrating experience is that a lot of people think that learning to code is learning a syntax of a programming language, and if you could just do away with that pesky syntax, everybody could code. But, obviously, the syntax ist just the initial barrier, and actually coding is crystallizing and formulating intent - something which programming languages are much better at than natural languages.&lt;p&gt;But for some reason, this low&amp;#x2F;no-code idea never seems to die down, especially in some spaces, and I have the feeling I&amp;#x27;m just missing something here.</text></item></parent_chain><comment><author>rurounijones</author><text>&amp;gt; I will never understand the reason for Cucumber to exist&lt;p&gt;In a previous company I had one use-case that I thought cucumber helped out a lot at.&lt;p&gt;We were writing software that would be vigourously tested and approved by a customer who didn&amp;#x27;t have any technical knowledge. Their initial plan was the &amp;quot;Excel sheet of death&amp;quot; test case management system with really fuzzily named tests.&lt;p&gt;I convinced them to write Cucumber tests, which turned out to be around 100, using the very explit syntax that then got called stupid by the cucumber devs and moved to the &amp;quot;training-wheels&amp;quot; gem. I never expressed what we were doing as cucumber tests. I just told them &amp;quot;Write them like this and it is easy to understand&amp;quot; and they agreed and did so, then they were signed off by our project team and them.&lt;p&gt;After that I then automated them our side so that we could run them quickly and easily in our pipeline while the customer could still use the tests for their tedious manual user acceptance testing at the end.&lt;p&gt;It worked out quite well. The customer never knew we automated the tests our side, they were just thrilled that something like 99% tests passed first-time and the 1% that didn&amp;#x27;t were down to interpretation differences.</text></comment>
<story><title>Robot Framework: generic open source automation framework</title><url>https://robotframework.org/</url></story><parent_chain><item><author>abracadabra_</author><text>I will never understand the reason for Cucumber to exist. As you say, it just introduces unnecessary complexity for no reason.&lt;p&gt;If you can&amp;#x27;t code, you shouldn&amp;#x27;t be writing automated tests. Most of the &amp;quot;benefits&amp;quot; of Cucumber can be gained by using a good reporting framework. I like to use Serenity as I love its reports.</text></item><item><author>lvncelot</author><text>I am less than lukewarm on those sort of &amp;quot;Natural-Language-Like&amp;quot; DSLs that seem to mostly come out of the QA space.&lt;p&gt;When I worked together with a QA team for automated testing, they used Cucumber, which uses Gherkin as an english-but-not-really DSL. Now the idea is obviously, that someone who doesn&amp;#x27;t know how to code can still describe and read test scenarios. But what ended up happening eventually is that I spent a lot of time writing code to support different Gherkin expressions, but then had to take over writing the Gherkin expressions as well, because even though Gherkin -looks- like english, it still behaves like a programming language. In the end, it would&amp;#x27;ve been much easier for me to just write the tests in a programming language from the start, instead of using an abstraction layer that turned out to serve no purpose.&lt;p&gt;What I took away from that frustrating experience is that a lot of people think that learning to code is learning a syntax of a programming language, and if you could just do away with that pesky syntax, everybody could code. But, obviously, the syntax ist just the initial barrier, and actually coding is crystallizing and formulating intent - something which programming languages are much better at than natural languages.&lt;p&gt;But for some reason, this low&amp;#x2F;no-code idea never seems to die down, especially in some spaces, and I have the feeling I&amp;#x27;m just missing something here.</text></item></parent_chain><comment><author>bluGill</author><text>The fact that gherkin can be be turned into an automated test is a side effect.  The real purpose is to get non-programmers to put their requirements in a rigorous form so that programs can implement the spec and know it will do what is intended.&lt;p&gt;I have never seen it work in practice, but that what it is supposed to be about. If your managers are not looking at the gherkin and making suggestions then there is no point in doing it.</text></comment>