[null, {"document_url": "http://www.michael-whelan.net/custom-reports/", "unformatted_src": "/images/bddfy-sample-atm-html-custom.png", "src": "https://www.michael-whelan.net/images/bddfy-sample-atm-html-custom.png", "formatted_filename": "bddfy sample atm html custom"}, null, {"document_url": "http://www.michael-whelan.net/custom-reports/", "unformatted_src": "/images/bddfy-custom-text-report.png", "src": "https://www.michael-whelan.net/images/bddfy-custom-text-report.png", "formatted_filename": "bddfy custom text report"}, null, null]
BDDfy In Action: Custom Reports

posted on 23 May 2013 | BDDfy | TestStack

This article is part of the BDDfy In Action series.

This post looks at how to customize the HTML Report and how to create your own custom reports. You can customize the HTML report via configuration or by applying custom CSS or JavaScript. You can create custom reports either by implementing a new Processor or Batch Processor and adding them into their respective pipelines (see the BDDfy Architecture Overview for details about the differences between these).

Customizing the HTML Report

The HTML report is the most sophisticated report in BDDfy and therefore provides a lot more things that you can configure. Its configuration is defined by the IHtmlReportConfiguration interface.

You can create a new configuration by implementing that interface or you can inherit from the DefaultHtmlReportConfiguration class, used to configure the standard HTML Report, and just override specific properties. Here is an example of a custom configuration, taken from the ATM sample, available on github here.

which produces the following customised report, which you will find in your bin directory named ATM.html: The HTML report is a Batch Processor and is implemented by the HtmlReporter class. To plug the new report into BDDfy you need to create a new HtmlReporter and pass the custom configuration into its constructor. As I explained in the Reports post, the place to apply that configuration to BDDfy is the Configurator class, which is called before the tests run.

The use of the Add method means this is adding a second HTML Report processor into the Batch Processor pipeline, so the default report runner will still run. If you actually want the new report to replace the default report, then you will also need to disable the default report.

Custom CSS and JavaScript

You can customize a lot more about the HTML report. BDDfy uses the BDDfy.css file to style the report and BDDfy.js and jQuery to add interactivity to it. You will find these files in the bin directory alongside the HTML report. You can customise the styles by adding a bddifyCustom.css class and the behaviour by adding a bddifyCustom.js file. These files also need to be in the same directory as the HTML report file. This will affect all the reports in the project.

Create a custom report by creating a new Processor

One way to create a custom report is to implement a new Processor and plug it into the Processor pipeline. You just have to implement the one Process() method and set the Process Type to Report.

An example of doing this is provided in the BDDfy Tic Tac Toe sample project with the Custom Text Reporter. The sample is available on github or nuget.

This produces the BDDfy-text-report.txt text file report which is output to the bin directory: Create a custom report by creating a new Batch Processor

While that is one way that you can create a custom report, probably the better way to do it is to implement a new Batch Processor. The Processor runs as each test is being executed and allows you to build up the report, whereas a Batch Processor has the advantage of running after all of the tests have finished, meaning that you have access to total and summary information, such as diagnostics.

As an example of creating a custom report by creating a new Batch Processor, I was recently messing around with running tests in parallel and, as you might expect, the normal console report was quite jumbled. Multiple console report Processors were writing to the console at the same time and different test results were overlapping. The solution was to run the console report after all of the tests had run by creating a new Console Reporter as a Batch Processor rather than a Processor.

Then I just needed to add it to the Batch Processor pipeline and disable the built-in console report:

That's a bit of a hack for demo purposes. The HTML, MarkDown, and Diagnostics reports are all implemented as Batch Processors and I would recommend checking them out for examples of how to create a new report.

About Michael Whelan