I mean, this video is as good as previous one about diving into cucumber, thx Ohayo-Dev, well-done, this is something that you won't find in the documentation of cucumber, because mostly the author is just sharing his experience.
Thank you for this very good second step in BDD!. Could be great if you include in your 3 video a reference to the other two, in order to start properly!
At 3:37 the example with multiple Whens is something I try to avoid. It breaks the Arrange, Act, Assert paradigm and has lost sight of the feature test experiment we are trying to create.
Hi! Thanks for the video. I wanted to comment on how we are moving away from using Gherkin to describe screens since that should be done with mock ups or wireframes and get your thoughts on that. It hasn't been valuable for us to try to take something that should be a visual requirement and turn it into words rather than using images. We are using Gherkin to illustrate our business requirements only. Nothing technical or screen focused since those things may continue to change over time as our technology changes. Where the underlying requirement will most likely remain the same. For example, let's say our business wants to allow our customers to obtain an identification card for the vehicle that they are insuring. How we provide that to the customer may change and each layer of the system that needs to do something in order to make that work will have some role in it's implementation. If the GWT is written: Given a customer with an active policy When the customer requests an ID Card for the Then the system will provided the ID Card And the ID Card will be for the Each layer of the system (Client/API) can implement this requirement and automate it to make it a living requirement in that application. As the technology changes, the implementation may change but the requirement will remain the same. What are your thoughts on this? Thanks!
Hey, I just started using cucumber at my job, and i'm looking for ways to clean up the codebase and make improvements. Thank you for this video. Also, do you have any recommendations for books/resources where I can learn Cucumber, particularly for Java development.
You can but generally it is best practice to keep it to a single Given, When, Then. However, this is the real world, so if you find yourself needing to break convention and you have a good reason to do so, then you should do what you need to do in order to make the best product possible
Please provide a couple of examples on handling multiple actions within a scenario, for example within a mobile app for a scenario of Search for an employee name , - a user might want to search thru navigation bar. Things like search results shown and have a cancel option (cross icon)...can we describe in a sentence Cancel option behavior (cancels and redirects to the search bar) within the above scenario itself?? else how do we handle such situations?
As mentioned before: Multiple When Then-Pairs are not Best Practise - cardinal rule says: 1 scenario describes one behaviour. And having multiple when-conditions (by adding all the AND's - see 18:56) is not ideal either.
There are a couple different ways you could do that. One way would just to write data to a flat file such as a CSV that you could retrieve in later steps. There are various libraries you could use in the step definition to save and retrieve data. If you want the data from one step to be used in later steps just note that it would tie those steps as dependent which does go against some of the guidelines laid out in Cucumber.
I usually do it if it is a parameter that can be changed. Like you could replace visible with disabled or invisible, and the step would still be viable taking in whatever is in quotes as a parameter
@@TheOhayoDev absolutely it would be very beneficial to have a cucumber setup guide, I mean the entire configuration with respect to cucumber. All the dependencies that are needed to start with cucumber (BDD) Framework
My preference is that the feature file name contain something that tells me what the feature being tested is. And, that doesn't mean a link to a jira ticket. If your feature is SMS features, maybe you name your file sms.features.
