Using TestNG to drive "eyeball" testing

Second of my Best of Internal Blog (BoIB) series originally posted on 9/6/2007 and updated 11/14/2007

In my daily job, I do something that NBC would consider "green". I digress, but wasn't that an awful promotion last week? I help large companies save paper (and money) by presenting documents they would normally send to their customers through the mail. 99% of these documents are bills.

During my time working with various documents, I developed a tool based upon the testing framework TestNG. This tool allows us to look at a "cycle" of documents and test various things on each of them. We need to be sure that we're presenting each item to the user as it looks on their paper statement. It is most useful when we have a client who cannot generate an edge case test file for us due to the legacy nature of the billing system.

I had an opportunity to dredge it up again. The code for this tool is over two years old, but works relatively well with little fanfare. It grabs a list of identifiers from the database for each document, generates a URL to each document and then browses the HTML document using HtmlUnit. However, I recently found it has a new use.

The latest use is PDF testing. Some of our clients use a document format from IBM known as AFP. It's a high speed printer format, but it is similar to PDF in many ways in that it describes where on a page to display text. It is possible to generate a PDF document from and AFP document using a number of tools.

So how can the document tester help? Simple, create a special test class that is setup to archive the PDFs for each statement to disk.

Here's the test method inside TestNG (obviously I'm not repeating all of the bootstrappy type stuff that gets the URL to the document)

@Test(parameters = {"filePath"})
public void testGetPDF(String filePath) {
 List formList = theDocument.getForms();
 Iterator formIterator = formList.iterator();
 // 1st Form gets the PDF
 HtmlForm myForm = (HtmlForm) formIterator.next();
 HtmlInput myInput = myForm.getInputByName("viewDocument");

 try {
   Page newPage = myInput.click();
   WebResponse resp = newPage.getWebResponse();
   ByteArrayInputStream pdfStream = (ByteArrayInputStream) resp.getContentAsStream();
   ByteArrayOutputStream baos = new ByteArrayOutputStream();
   File pdfFile = new File(filePath + this.theDocumentID + ".pdf");
   FileOutputStream fos = new FileOutputStream(pdfFile);
   int count = 0;
   int data = pdfStream.read();
   while (data > -1) {
     count++;
     baos.write(data);
     data = pdfStream.read();
   }
   baos.flush();
   baos.writeTo(fos);
   baos.close();
   fos.close();
   pdfStream.close();
 } catch (Throwable t) {
   org.testng.Reporter.log("Throwable: " + t.getMessage());
   t.printStackTrace();
 }
}

Pretty neat! Now you get a directory full of PDFs that you can archive and ship off to your customer, or browse yourself. It sure beats a manual process of click and reload, and assures a proper test of using the actual application to generate the document. You could obviously save HTML or CSV files as well, but they can be tested using classes within the testing tool, which is obviously more efficient. This is simply making "eyeball" testing a bit faster.