667
Like
Share
ReportI wanted to write this review for a selfish purpose, to keep in my mind all what I learn in this book. I strongly recommend the book for these reasons:
- Is a book both for reference and for complete reading.
- The approach of the subject is complete, but the book is very easy to read, and not too big.
- Isn´t a dogmatic approach to Test Automation, instead includes a set of very pragmatic advices to begin with Test automation.
- Despite could be a good book for other techs out of NAV world, the book is intended to be read by NAV/BC people, with an incredible description of NAV/BC Test Tool. Special mention to the chapters dedicated to pass standard tests with our customizations. The step by step lab to pass these tests is brilliant and useful. When we think in test automation we always think about test our features, forgetting the free and already made tests of the standard, that could discover a lot of problems in our own features.
- Test libraries includes a lot of incredible pieces of code, and some of them are the kind of crazy stuff that I love. The book shows us some of these and tips to explore these libraries to find interesting features.
The rest of the post I will highlight tips that gets my attention, beyond the basics.
Testing the test. Refactoring the test
In every test made in the book, there is a section “Test the test”. If the test code never failed, you are not sure if it is testing properly. So, you must force a test fail once.
There are several techniques to get this:
You can force the error in the value check:
//OK SalesHeader.TestField(Amount,ExpectedAmount);
SalesHeader.TestField(Amount,ExpectedAmount+20);//Will fail
If the test has an assert error statement you can remove it to make the test fail:
//OK asserterror MyProcedure;
MyProcedure;//Will fail
Code refactoring in test code is easier because the test itself ensure that all remain working after code modification.
Some crazy stuff: libraries
The test libraries have lot of interesting code, we can do many operations with documents, journals, tracking, dimensions, posting, there are many examples of Recordref handling for a broad range of uses, generating of random data, etc.
Reading the book, I discovered two libraries:
“Library Report Dataset” Codeunit: This library with a simple function call load all the report content in an XML structure:
with LibraryReportDataset do begin
RunReportAndLoad(Report::"Sales - Invoice", SalesInvoiceHeader, '');
end;
You can navigate between rows, find a row with a value, test the value of a column with very simple functions:
with LibraryReportDataset do begin
RunReportAndLoad(Report::"Sales - Invoice", SalesInvoiceHeader, '');
FindCurrentRowTagValue('No.', ItemNo);
AssertCurrentRowValueEquals('Quantity',ExpectedQty);
end;
Library Variable Storage: This Codeunit store and manage a LIFO collection of variant data. The Codeunit acts as a LIFO queue and you can enqueue, retrieve and dequeue elements.
Other advanced features
- Test Coverage Map is a feature, that allow us to run only test related with modified objects or selected objects. This feature is based in Code Coverage.
- Raising events and Shared fixture pattern. Standard test publish some events on initialize: OnBeforeTestSuiteInitialize and OnAfterTestSuiteInitialize. This allows us to fix some problems running standard test with our customizations.
*This post is locked for comments