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, programming is not easy. Errors can arise at each step.

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.

It was long overdue to develop an easy-to-use test system.

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

The interface of PDFUnit-XML is tightly coupled to the API of PDFUnit-Java and follows the "Fluent Builder" principle. The names of the XML tags are similar to everyday speech to support general thought patterns. This results in XML that is easy to understand for a long time.

The next example shows the simplicity of the API:

<testcase name="compareText_OnEveryPage">
  <assertThat testDocument="master/documentUnderTest.pdf"
              masterDocument="master/masterDocument.pdf"
  >
    <haveSameText on="EVERY_PAGE" />
  </assertThat>
</testcase>

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 to write successful tests.

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