Cucumber: Identifying slow steps that drag down your test speed

Updated . Posted . Visible to the public. Repeats.

In most projects I know, Cucumber test suite speed is not an issue. Of course, running 350 features takes its time, but still each test for itself is reasonably fast. There is nothing you can do to fundamentally speed up such a test (of course, you should be using parallel_tests).

However, in projects that go beyond clicking around in a web GUI and checking results, there might be various measures to speed things up. Katapult Show archive.org snapshot tests for example could be sped up more than 4 times by reusing a cached Rails application, and the tests for a video player we built could also be sped up significantly by using a local video stream instead of a remote one.

But how can you find out which optimization is worth the effort?

cucumber --format usage to the rescue

Fortunately, Cucumber has built-in support for this. Run tests (serially) with --format usage, and it will measure each step's runtime. When all tests are run, it will print a list of all run steps, grouped by their definition, sorted by their average duration. From this output you should be able to easily determine potential for optimization. Profit!

Note that steps that wait on an effect (like "I should see …") reveal the slowness of the previous step.

cucumber-format-usage.png

Dominik Schöler
Last edit
Jonas Schiele
Keywords
performance, speed
License
Source code in this card is licensed under the MIT License.
Posted by Dominik Schöler to makandra dev (2017-10-12 06:39)