 Although I’ve been using Cucumber for a long time, it wasn’t until I started working at Macy’s that I really began using it. Back then, it was a way for me to document my test cases and get automated integration tests in place. It was easy when I worked on projects were I was the only QA engineer. As I got integrated with the bigger projects, it was back to the traditional waterfall of development. Because we were an enterprise company, best practices some times went out the door, because of code freezes and features had to get out the door by a particular date to meet some sale. Everyone above my pay scale saw the value in cucumber, but modified it to meet their organization. Still, we never achieved the intent that Cucumber brings to the table.
So, what value does Cucumber bring to the table? First and foremost is the power of the feature file. Written well, it can tell the whole team involved in the project what it is they are developing. Here’s a simple feature file for a feature to generate folders that an application downstream will read from. Upstream there is an application that will submit a new job id to be processed. folders.feature Feature: As an application, I would like to have folders based on job ids, so that I can download daily reports to that folder. Scenario: I want to have a folder created named after the job id Given I have a new job id to process When I read the list of job ids Then I should have a new folder named after the new job Scenario: I want to have a subfolder with today’s date in the new job id folder When I have created a new job id folder Then I should have a new folder with today's date Scenario: I want to have a new date folder in an existing job id folder When I start a new day on my existing job Then I should have a new folder with the new date The feature file is simple and straightforward. You may wonder why there are no more than three steps in each scenario. The reasons for this is:
For those unfamiliar with cucumber, here’s the breakdown of the keywords that are in bold. Feature - High level description of the feature this file covers. Over the years, I’ve become a fan of writing this section in the “As a/an …, I would…, So that…”. This helps me to enforce ownership in the work I’m doing for this feature, whether as a product owner, developer, or tester (the three amigos). Scenario - I equate this to an acceptance criteria. It focuses only on one thing and that is the only thing I will test for this scenario to be accepted. Just like the feature file, I tend to write my scenarios with “I want to …” Given - Equivalent to a precondition step in a test case. Not always required in every scenario. In this case, because I plan to develop integration tests for this feature, the Given step will apply to all my scenarios. There is a keyword called Background in cucumber, but I tend avoid using it for performance reasons. When - Equivalent to the test step in a test case. Then - Equivalent to the expected results in a test case Notice that the Given/When/Then are followed by I. This just continues the “ownership” concept that developing in cucumber brings. Nouvola has a great video that best explains what I currently do today. Join AI trailblazers, machine learning experts, forward-thinking executives, and product and engineering innovators for this one day event to learn how AI is being applied to real business problems. Train AI will feature keynotes from industry leaders, real world case studies on practical machine learning applications, an exclusive Executive Briefing Center, and an AI solutions showcase with market-leading technologies and solutions.  Use the promo code 'Melvin50' and get half off.
|
RSS Feed
