LOGIN | REGISTER NOW | SUBSCRIBE
 
Print

How to speed up your Cukes


By John Sextro


 John Sextro
Email
May 14, 2012 —  (Page 1 of 3)
Let’s face it, you can never have enough money and your tests never run fast enough. I can’t help you with your money, but if you follow the steps in this article, I can help you speed up your Cucumber tests.

The improvement process that I’ll walk you through is known as DMAIC (Define, Measure, Analyze, Improve, Control). DMAIC is an improvement cycle commonly used in Six Sigma to improve and optimize business processes. Let’s take a look at how it works.

Define: You’ve probably already defined the problem and have determined that your tests are too slow. What you haven’t done is define success. You will define success in terms of execution time. For instance, if your Cukes are taking 30 minutes, you might define success as, “Make all Cukes run in 20 minutes or less.” The target is up to you and your team to decide. Just remember, the amount of time it takes to run your tests will be inversely proportional to the number of times you will run them. So the faster they are, the more often you will run them.

Measure: You know how long it takes to run the suite. You might even know how long it takes to run each scenario or sets of scenarios. What you need to know now is how long it takes each step to run. But wait: Before you go diving back into your steps to instrument them with timers, let’s step back and see what Cucumber can do to help us.

Fortunately, Cucumber offers a number of helpful options for formatting the output of our test runs. One of those options is format usage. Using the “usage” format will show us which steps take the longest to run, how many times each step is executed, and if any steps are unused. As shown in the usage report, I’ve slightly modified some of the example feature files provided with the Cucumber source to generate the following output.

Cuke output

Analyze: With our new data in hand, we can begin to zero in on the trouble spots. The usage report displays the steps ordered from slowest to fastest. The report also shows the number of times each step was executed. Your slowest step might not be the biggest problem. You should focus on the steps that run the slowest and the most often. Also, consider why the step was executed so frequently. If you wrote the scenarios following a behavior driven development (BDD) cycle, then the scenario was written to define behavior in the system. As a result, you may find many scenarios exercising the same part of the system in only slightly different ways. By viewing the scenarios in hindsight, you can consider if you should consolidate or eliminate some of the scenarios.


Related Search Term(s): agile, Cucumber tests

Pages 1 2 3 


Share this link: http://sdt.bz/36616
 
Most Read  Latest News  Resources
SAP unveils SAP HANA platform innovations for Big Data and spatial processing
Features include smart data access and expanded cloud deployment options
Alteryx raises $12 million to put Big Data analytics in the hands of all business analysts
Quest founder's firm, Toba Capital, selects Alteryx as its first analytics investment
Google I/O kicks off
Developers get new APIs and tools, and the Go language hits version 1.1
Jelastic launches new version of its Java and PHP hosting platform
Jelastic today announced the launch of a new version of its ultra-scalable cloud hosting platform
Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter


close
NEXT ARTICLE
Finding the right tool for the agile job
Experts emphasize that tools should bolster the agile process above all else Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
MAY 2013 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?