Introduction

In this previous post I commented Luc Van Vugt´s book and highlighted many advanced features of AL testing suite:
I talked about Library Report Dataset, a Codeunit that helps us to run a report, saves its layout content in XML and eases navigate and check values in this layout. With this Library you can navigate across the report rows , filter these rows, sum row values and check column values.

Who cares?

Why should I make tests for data display reports? We often feel testing is only for the internal logic, actually a couple of years ago I agreed with this idea, and I thought test report data display was not a really important stuff. But, releasing a version of my company add-on I received a lot of complaints, due to an error in our printed invoice. The execution crashed, due to an obsolete field in sales invoiced line. As you may know, obsolete fields don´t crash compilation, but crash the execution when we use the obsolete field.
The fix was very simple, but when you have a published version, distribute the fix is not so simple. If I tested report data display as I tested with business logic, I did not spend a lot of time fixing errors on the go.
I am not talking about a deep layout test. I think we only have to run it without crashing and check one important layout field. We have Microsoft continuous message about avoiding breaking changes, but obsolete fields are a subtle way to break the app:
        field(10700; "Pmt. Disc. Given Amount (Old)"; Decimal)
        {
            ObsoleteReason = 'Merged to W1';
            ObsoleteState = Removed;
            ObsoleteTag = '15.0';
And we must think too in SAAS, with no control about update times of our customers.
And again, I am not talking about forcing teams to a deep test for display features, if we only make a test to ensure a complete execution and a simple display data checking, we will improve a lot our publishing accuracy.

Hands-on.

Now let´s do a very simple test:
  • Make a sales invoice.
  • Check the report Sales invoice runs properly.
  • Sum for the document line amount in report and in table, and check both matches.

How many code lines do we need for this?

// [When] Exercise: 
LibraryReportDataset.RunReportAndLoad(Report::"Standard Sales - Invoice", SalesInvoiceHeader, '');
TotalPrinted := LibraryReportDataset.Sum('LineAmount_Line');
SalesInvoiceLine.SetRange("Document No.", SalesInvoiceHeader."No.");
SalesInvoiceLine.CalcSums("Line Amount");
// [Then] Verify:         
Assert.AreEqual(SalesInvoiceLine."Line Amount", TotalPrinted, '');
Is not too much. The parameter of the Sum function 'LineAmount_Line, is the name of the layout column. We must go to report design and get this name:
                column(LineAmount_LineFormattedLineAmount)
                {

Library Report Dataset.

People that make automatic test, sometimes feel they can be addictive. You make a simple test, was easy, then you want to make a more complex test, and so on. If you want a deeper test of your reports, Library Report Dataset gives a lot of outstanding features. Here we are a screenshot of its main methods:
This Codeunit is number 131007 in Test library app: