Discussion:
[Cucumber] Misuse of cucumber
(too old to reply)
Tobias Bell
2018-04-09 20:03:18 UTC
Permalink
Hi everyone

while I really like the idea of executable specifications, I am currently
surrounded by feature files like this:

Given a valid call "valid.json"
When the service is called
Then the result is "result.json"

Maybe be slightly exaggerated but you get the drift. Now I have to look at

- the feature file
- the data files
- the stepdefs

to understand what is happening. And people are okay with it

- It's easy to create more tests, just add two json files
- Ok, you don't understand it but the business (aka developers who wrote
it) understand it

Is it just me, or is this not a good use of cucumber? The other thing
nagging me. Scenarios which are essentially unit tests.

What do you think of it? Have you ever come along this?

Regards
Tobias
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
aslak hellesoy
2018-04-10 13:41:29 UTC
Permalink
Post by Tobias Bell
Hi everyone
while I really like the idea of executable specifications, I am currently
Given a valid call "valid.json"
When the service is called
Then the result is "result.json"
Maybe be slightly exaggerated but you get the drift. Now I have to look at
- the feature file
- the data files
- the stepdefs
to understand what is happening. And people are okay with it
- It's easy to create more tests, just add two json files
- Ok, you don't understand it but the business (aka developers who
wrote it) understand it
Is it just me, or is this not a good use of cucumber?
No, this is typical bad use. Scenarios with implementation details are
better expressed as unit tests, using a unit testing tool.

If you can't get feedback on your scenarios from a non-technical
stakeholder it is just overhead IMO.
Post by Tobias Bell
The other thing nagging me. Scenarios which are essentially unit tests.
What do you think of it? Have you ever come along this?
It's more common than you think. Unfortunately, most people using Cucumber
still think it's a testing tool.
https://cucumber.io/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool

Aslak
Post by Tobias Bell
Regards
Tobias
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Tim Walker
2018-04-10 14:02:43 UTC
Permalink
[tim] below
Post by Tobias Bell
Hi everyone
while I really like the idea of executable specifications, I am currently
Given a valid call "valid.json"
When the service is called
Then the result is "result.json"
Maybe be slightly exaggerated but you get the drift. Now I have to look at
- the feature file
- the data files
- the stepdefs
to understand what is happening. And people are okay with it
- It's easy to create more tests, just add two json files
- Ok, you don't understand it but the business (aka developers who
wrote it) understand it
Is it just me, or is this not a good use of cucumber? The other thing
nagging me. Scenarios which are essentially unit tests.
What do you think of it? Have you ever come along this?
[tim] Always. For 20 years now. Unless we "publish" our executable
specifications the value of them to continue to communicate as living
documentation is greatly diminished. I am firmly in the camp of of treating
our Cucumbers as our gold standard for documentation about the system but
the "Given/When/Then" abstraction, in both imperative and declarative usage
can be onerous to read, either there's not enough information to make it
valuable or there's too much of it to make it worthwhile to read. I remain
dedicated to the concepts of www.relishapp.com and extensible plugins to
augment our specifications with images, text, markup, links, screenshots
and more. I feel we are on the cusp of really taking this to town and I see
ALM tools even baking in executable specifications. In your example, why
not have a rich UI to drill down from the features to the tables and
underlying assertions, at any level in the system? Are we limiting our
thinking and constraining the power of the approach? Tim
Regards
Tobias
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Andrew Premdas
2018-04-13 09:56:54 UTC
Permalink
When writing scenarios you have to understand what is the purpose of
reading them, and who are the audience. Cucumber was designed as a tool to
drive development, so having a feature working that is as simple as

Scenario: I can sign in
Given I am registered
When I sign in
Then I should be signed in

is actually extremely valuable. It succinctly captures the idea that this
complex operation of signing in is working. Most readers of this have no
need to know when they are reading this output about HOW sign up is
implemented. They have even less need to know about HOW registration is
implemented. And when something goes wrong and you can't sign in, the
scenario quickly tells you what has gone wrong and its implementation is
easily accessible through simple step definitions which are easy to find
because there are no parameters, regex's example tables etc, to navigate.
Instead the implementation takes you right to the heart of the problem.

Viewed as one scenario you may feel that more information may be valuable,
but when you have several hundred scenarios to manage you will appreciate
the brevity and the consistent delegation of HOW things are done to things
lower down the stack. If the lower details of the stack are implemented
with some consistency then you can pick up the patterns of how things are
delegated and where files are located.

However the above scenario is very different to you sample scenario because
it is using one piece of named behaviour 'registration' and is defining
another piece of named behaviour 'signin'. Your example is relying on the
code lower down to do this naming. The difference is subtle and huge at the
same time.

Now you could be misunderstanding and misrepresenting the work in your
codebase with your example. Or perhaps you codebase really does have simple
scenarios that don't actually do any naming. We would need to see actual
examples in context i.e. with the feature pre-amble and the scenario
description to judge this.

Finally this sort of complaint is something I see all the time with code.
Alot of less experienced programmers feel that have big methods that deal
with HOW something is done is much simpler than using concepts like single
responsibility, delegation etc. etc. . Breaking things into lots of small
simple chunks always creates problems with navigating those chunks and
following the path of delegation. But its the only way to effectively deal
with complexity. You have to abstract, name and delegate to get simple
usable definitions of behaviour, and that inevitably hides the complexity
behind that task as something you have to delve down into if you want to
explore further.

I'll finish with another example

Scenario: A new user can register
Given I am a new user
When I register
Then I should be registered

Registration can be simple or extremely complicated. Its also likely to
change over the lifetime of the application. Having a simple scenario that
introduces/names the concept 'registration' and confirms that registration
is working is very useful. Not having to change this scenario every time
you make a small adjustment to say the rules for a safe password is also
very useful. When you have this scenario you can then easily have Given I
am registered, which means that you can then have Given I am signed in, and
that will be used in most of your scenarios.

None of this stops you testing password rules exhaustively somewhere else,
which is something you may want to do. But testing and in particular
exhaustive testing should not be done with Cucumber, its not a testing
tool!! Its far more efficient to use Unit tests, both for writing time and
even more importantly execution time.

Hope thats useful. I'd be interested to see some real examples to comment
further

All best

Andrew
Post by Tobias Bell
Hi everyone
while I really like the idea of executable specifications, I am currently
Given a valid call "valid.json"
When the service is called
Then the result is "result.json"
Maybe be slightly exaggerated but you get the drift. Now I have to look at
- the feature file
- the data files
- the stepdefs
to understand what is happening. And people are okay with it
- It's easy to create more tests, just add two json files
- Ok, you don't understand it but the business (aka developers who
wrote it) understand it
Is it just me, or is this not a good use of cucumber? The other thing
nagging me. Scenarios which are essentially unit tests.
What do you think of it? Have you ever come along this?
Regards
Tobias
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
------------------------
Andrew Premdas
blog.andrew.premdas.org
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...