Customise testing report


I would like to be able to generate a report in my own way with my own content.

I want to know whether and how to capture a test result and write something out to a separated file if a particular test failed.

For instance, for the given control below:

describe security_policy do
  its('PasswordComplexity') { should_not be 0 }
  its('MinimumPasswordLength') { should be >= 10 }

I want to write a test report into a file A.txt if the PasswordComplexity is disabled, (ie the its(‘PasswordComplexity’) { should_not be 0 } test failed), and want to generate another report in B.txt when the PasswordComplexity is enabled (ie the its(‘PasswordComplexity’) { should_not be 0 } test passed) but the min password length is less then 10.

Any hints will be really appreciated.

Thanks in advance.


You could define the output of the InSpec result as json and parse the json object accordingly


Another way to address this problem would be to create a customer formatter and use that formatter when running inspec exec. However, I don’t actually believe that the InSpec CLI allows support for customer formatters without some monkey patching.

Because inspec does not support --require ... --format ... the only point of entry I see would be to write a formatter (Ruby class) as a ruby file and include it a profile.


Another workaround would be to catch the exception generated when the expectation fails and then write out something to a file. This isn’t really that great of a solution either:

describe security_policy do
  it 'has password complexity enabled' do
      security_policy.PasswordComplexity.should_not be 0
    rescue Exception => e
      File.write('A.txt','PasswordComplexity is disabled')
      raise e

This is an example of how you could intercept the exception generated from the failure, write out a file upon failure, and then continue to raise the exception up the stack so that the example fails.

This does not include the logic if one passes and the other does not. I assume that these may be tied together so you might not need to worry about that but if you did, you would likely have to combine both of these expectations, maintain some state (hard if the expectations are run in a random order), or do some introspection on RSpec to see if the other example has failed.

I don’t recommend this as a long term solution or something that you would want to litter throughout your controls but wanted to give you something that you could possibly use if you must have this feature.