Cucumber’s default behavior is to output results similar to the Gherkin source text—with a little extra information such as colors, locations of matched step definitions, highlighting of arguments, and so on. This isn’t the only way to output results. Cucumber lets you use a different output format. For example, if you want a minimal report with a single character per step, you can use the progress formatter:
| $ cucumber --format progress |
| ..U--..F.. |
Each character represents the status of each step:
Cucumber also has built-in formatters that output html, json, and junit. The latter is handy if you are running Cucumber in a continuous integration (CI) environment since most CI servers know how to interpret JUnit reports. More on that in a minute.
In addition to the formatters we have seen so far, Cucumber also bundles a few formatters that create output that isn’t really meant to be read as a report of the run. These formatters rather serve as a development aid.
The usage formatter lists all of the step definitions in your project, as well as the steps that are using it. It shows you unused step definitions, and it sorts the step definitions by their average execution time. The output from the usage formatter is great for quickly finding slow parts in your code but also a great way to get an overview of your step definitions.
The stepdefs formatter is similar to the usage formatter but with a little less information.
Finally, there is the rerun formatter. This is a special formatter that creates output like this:
| $ cucumber -f rerun |
| features/one.feature:367 features/another.feature:91:117 |
Does this look familiar? This is the same kind of format we used to run a subset of scenarios using line filtering, which we described earlier.
If all scenarios are passing, the rerun formatter doesn’t output anything at all. However, if one or more scenarios fail, it will output their location so that you can copy and paste the output to rerun just those scenarios. Being able to do this saves a lot of time when fixing broken scenarios.
By default, all formatters will print their output to STDOUT. So, what do we do if we want to see the usual pretty output but also have a html and rerun report? This is where you have to use the --out option. It tells Cucumber to write the report to a file instead of STDOUT. Here is an example:
| $ cucumber -f pretty -f html --out cukes.html -f rerun --out rerun.txt |
This tells Cucumber to write the HTML report to the file cukes.html, then rerun output to rerun.txt, and finally display the pretty formatter’s output in the console.
Using the --backtrace option causes Cucumber to print a full backtrace for each failure instead of a shortened one. This is useful when you are hunting bugs.