How to speed up your Cukes

By John Sextro

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.

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

Technorati

Digg

Slashdot

Facebook

Friendfeed

Twitter

del.icio.us

Finding the right tool for the agile job Experts emphasize that tools should bolster the agile process above all else

Jim Highsmith: Agile Manifesto has served the industry well Looking back at its creation, the Manifesto cosigner expects agile to embrace continuous integration and enter new industries

Ken Schwaber on agile: It pushed success rates beyond 45% SD Times interviewed the co-creator of Scrum to see why agile improved development practices so dramatically