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 BellHi 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.