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:
Is the expected text within the expected page region?
Is the bar code's text the expected text?
Does the layout fulfill the requirements?
Do the embedded ZUGFeRD data have the expected values?
Are the values of the embedded ZUGFeRD data correspond with the visible values?
Does a PDF comply with DIN 5008?
Is the PDF signed? When and by whom?
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.