Posted 3 months ago. Visible to the public. Repeats.

Cucumber: Identifying slow steps that drag down your test speed

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 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!

cucumber-format-usage.png

By refactoring problematic code and creating automated tests, makandra can vastly improve the maintainability of your Rails application.

Author of this card:

Avatar
Dominik Schöler
Last edit:
3 months ago
by Henning Koch
Attachments:
cucumber-format-usage.png
About this deck:
We are makandra and do test-driven, agile Ruby on Rails software development.
License for source code
Posted by Dominik Schöler to makandropedia