There are various strategies for testing the content of reports using automation. In this article we look at how we can render an SSRS report in memory and then query an XML representation of its content using X++.
If we develop a new or extend an existing SSRS report, it’s a good idea to add some further tests to our delivery pipeline to make sure it behaves as the user expects and to automatically pick up on any future regressions.
We could test the data set returned by the underlying report query, or by inspecting the contents of our temporary tables that supply data to the report, however this approach won’t necessarily pick-up on any defects introduced into the report design itself (encoding business logic into the report is not the best approach, but there are times when it is the only pragmatic approach.)
A different approach therefore is to test the content of the report once it has been rendered by SQL Server Reporting Services (SSRS) and converted into an XML format (it’s also possible to render to HTML, but that approach isn’t for the faint of heart!)
The report page model is held in memory by an XmlDocument object. For each report that we want to test, we can add further concrete pages with report implementation specific details:
And our tests can ask the pages about the values rendered in the reports without knowing about the underlying implementation details (hopefully making the tests less brittle.)
You can read more about test automation using the Page Object Model in this article.