Preface

These days telephone bills, insurance policies, official notifications and many types of contract are delivered as PDF documents. They are the result of a process chain consisting of programs in various programming languages using numerous libraries. Depending on the complexity of the documents to be produced, such programming is not easy. The software may have errors and statistically will have errors. So it should be tested in some of the following ways:

It should scare developers, project managers and CEO's that until now there is almost no way of repeatedly testing PDF documents. And even the options which are available are not used as frequently as they should be. Unfortunately, manual testing is widespread. It is expensive and prone to errors.

With PDFUnit, any document, whether created using a powerful design tool, exported from MS Word or LibreOffice, processed using an API, or dropped out of an XSL-FO workflow, can be tested.

The interface of PDFUnit follows the principle of "fluent builder". All names of classes and methods try to follow the English language as closely as possible and thus support general thought patterns.

The next example shows the simplicity of the API:

String filename = "documentUnderTest.pdf";
int leftX  =  17;  // in millimeter
int upperY =  45;
int width  =  80;
int height =  50; 
PageRegion addressRegion = new PageRegion(leftX, upperY, width, height);

AssertThat.document(filename)
          .restrictedTo(FIRST_PAGE)
          .restrictedTo(addressRegion)
          .hasText()
          .containing("John Doe Ltd.")
;

To write successful tests it is neither necessary for a test developer to know the structure of PDF nor to know anything about the creation of the PDF document.

Don't gamble with the data and processes of your document processing system. Check the output of the PDF creating programs with automated tests.