I wonder how you manage really complex situations? Let me try to describe it with a dumb example. Imagine you're writing specs for an app similar to instagram (and with really fine-grained control), and you end up writing a scenario like:
Scenario: get notified of a new reaction
Given I posted a picture on my account
And people are allowed to react on the picture
And notifications for reactions is turned on
...
And someone liked the picture
When I login
Then a popup is shown that someone reacted to my picture
I remember working with scenarios that had like 10 Given statements or so. And I couldn't really see how the number of statements could have been reduced.
You have to apply abstraction to merge several steps together. Or apply decomposition to separate them. Let me explain, please.
For example: you want to be notified when someone posts likes on your posts/images/etc. We all know and love this feeling. For this situation it does not really matter how did you create this content. You only write specs for the reaction part.
Feature: authors are notified about readers' reactions
Scenario: get notified of a new reaction
When a reader reacts on author's content
Then author gets a notification about it
Scenario: do not get notified about new reactions when notifications are disabled
When author's notifications for reactions are disabled
And a reader reacts on author's content
Then author gets no notification about it
This is a first feature: receiving notifications. Disabling the ability to react is a different feature. And should be specified as a different feature. Because notifications only make sense when readers are allowed to posts reactions. However, you can mention that all content for feature authors are notified about readers' reactions is allowed to be reacted on. You can use Background tag for that: relishapp.com/cucumber/cucumber/do...
Jon is a self-taught programmer, started in video games but now does web development. He follows principles, argues for scientific software development, and does not like writing in the 3rd person.
I only know the theory, but I think the scenario setup can be abstracted in the direction you talk about it in the office. That is, do you go around saying “let’s make a great notification feature for posts with notifications enabled and permissions are allowed and the user clicks etc etc”? No, you have some shorthand that the organisation accepts (or is ready to adopt). Internal language can have deep meaningful abstractions and that worth capitalising on. The BDD part of Gurkins is to identify those ways of talking.
Well, I think so at any rate. I think your question is really good and gets to the heart of the complexities with full behavioural test coverage.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Very good article! 🎉
I wonder how you manage really complex situations? Let me try to describe it with a dumb example. Imagine you're writing specs for an app similar to instagram (and with really fine-grained control), and you end up writing a scenario like:
I remember working with scenarios that had like 10 Given statements or so. And I couldn't really see how the number of statements could have been reduced.
You have to apply abstraction to merge several steps together. Or apply decomposition to separate them. Let me explain, please.
For example: you want to be notified when someone posts likes on your posts/images/etc. We all know and love this feeling. For this situation it does not really matter how did you create this content. You only write specs for the reaction part.
This is a first feature: receiving notifications. Disabling the ability to react is a different feature. And should be specified as a different feature. Because notifications only make sense when readers are allowed to posts reactions. However, you can mention that all content for feature
authors are notified about readers' reactionsis allowed to be reacted on. You can useBackgroundtag for that: relishapp.com/cucumber/cucumber/do...I hope this helps you.
Thanks for the reply!
Then this implies to me that I might end up writing long
Backgrounds.Do you maybe know some mature open source projects where they're doing BDD the right way? I would love to analyze something in depth.
Nope, sorry :sad:
I only know the theory, but I think the scenario setup can be abstracted in the direction you talk about it in the office. That is, do you go around saying “let’s make a great notification feature for posts with notifications enabled and permissions are allowed and the user clicks etc etc”? No, you have some shorthand that the organisation accepts (or is ready to adopt). Internal language can have deep meaningful abstractions and that worth capitalising on. The BDD part of Gurkins is to identify those ways of talking.
Well, I think so at any rate. I think your question is really good and gets to the heart of the complexities with full behavioural test coverage.