Using Test Data for PDF Generation

To test a PDF template, give it representative sample data with the same field names, nesting, and types as the payload your production generator will receive. Generate or preview the PDF, then inspect the rendered pages for missing values, overflow, broken images, incorrect repeated rows, and unexpected page breaks. Keep deterministic, synthetic fixtures for typical inputs and layout edge cases so template changes can be checked consistently.

For a JSON-driven template, your fixture is not just placeholder content: it is an example of the template’s data contract. A preview driven by that fixture can show how dynamic text, images, and loops render before real documents are generated. PDFMonkey documents this kind of sample-JSON preview and says the test JSON has the same structure as the payload sent through its API or dashboard. Adobe documents a different route: merge JSON into a Word-based template and invoke its Document Generation API to create a PDF or Word document. PDFMonkey’s documentation · Adobe Document Generation API

1. Decide what “PDF generation” means in your workflow

Test-data workflows differ depending on what receives the data and what produces the PDF. Identify the input model before building fixtures:

Workflow	Input	Feedback loop	Good fit
JSON-driven designed template	Structured JSON with fields and collections	Template preview, or generated PDF	Invoices, reports, proposals, and other documents assembled from application data
Word template merged with JSON	JSON plus a custom Word template	Generate a document through the API and inspect it	Teams authoring a document in Word and filling it with structured values
Fillable PDF form	Values mapped to existing PDF form fields	Populate the form and inspect the result	Filling an existing form rather than designing a whole document template

PDFMonkey describes sample JSON entered in a payload editor to populate text, images, and loops in a canvas preview. Adobe’s guide describes preparing JSON and invoking its Document Generation API with a Word template. IRI documents a narrower use case: populating PDF form fields from set-file data while preserving relationships among values in multi-column files. These are different workflows; a fixture designed for one is not automatically suitable for another.

2. Write down the template’s data contract

Before composing a fixture, inventory each dynamic value and how the template uses it. Record the key exactly as the generator expects it, its type, whether it is required, and what the document should show if it is absent or empty.

• Scalar fields: strings, numbers, booleans, and dates. Note expected formatting, such as a currency amount or a human-readable date.
• Optional fields: distinguish a missing key, an explicit null, an empty string, and a value. Decide whether each should be omitted, replaced, or shown as an empty state.
• Collections: list item keys, ordering assumptions, and behavior for zero, one, and several rows.
• Images: identify the expected URL or field, supported image behavior, and a fixture image the preview or generator can reach.
• Derived values: decide whether totals, labels, and formatted values come from the application payload or the template.

Use production key names and nesting. Renaming a fixture field to make it look nicer can hide a real integration bug. If the application sends customer.billing_address.postcode, test that exact path rather than a flatter substitute unless the template contract itself is different.

3. Create a representative JSON fixture

Start with a plausible typical document, then add cases that challenge layout. The JSON below is an illustrative fixture; adapt its keys to your actual template rather than assuming these are any vendor’s required schema.

{
  "document_number": "INV-2048",
  "issued_on": "2026-09-30",
  "due_on": "2026-10-30",
  "currency": "USD",
  "customer": {
    "name": "Jordan Lee",
    "company": "Northwind Field Services",
    "email": "jordan@example.test",
    "address": {
      "line1": "18 Market Street",
      "line2": "Suite 420",
      "city": "Portland",
      "region": "OR",
      "postal_code": "97205"
    }
  },
  "logo_url": "https://example.test/assets/logo.png",
  "items": [
    {"description": "On-site installation and configuration", "quantity": 2, "unit_price": 425.00},
    {"description": "Annual support plan with extended coverage", "quantity": 1, "unit_price": 180.00}
  ],
  "subtotal": 1030.00,
  "tax": 82.40,
  "total": 1112.40,
  "notes": "Please include the document number with payment."
}

Keep the fixture internally consistent where the document displays related values: item quantity multiplied by unit price should agree with line totals if present, and the displayed subtotal, tax, and total should make sense together. Inconsistent examples can be useful for testing error handling, but they should be clearly named and kept separate from the normal preview fixture.

Then make purposeful variants. A compact set can include the normal case above, a long-content case, and an empty or boundary case. You can store each fixture as a separate JSON file or load variants into a builder, depending on the workflow.

Coverage checklist

• Typical values and realistic combinations
• Short and unusually long names, addresses, descriptions, and notes
• Optional values missing, empty, and populated
• Collections with zero, one, and multiple entries
• Text containing punctuation, non-ASCII characters, and line breaks if users can enter them
• Small and large numeric values, including values near formatting or rounding boundaries
• Dates at month or year boundaries, and the formats the application actually sends
• Valid image URLs, and missing or unavailable images if the template must handle them
• Values that produce the longest realistic page, table, or repeated section

Do not put customer records or copied production payloads into a shared preview just because they are convenient. Use fabricated values or appropriately mocked values for privacy-sensitive testing. Katalon documents data modes that include raw data, raw data with PII mocked values, and synthetic values; BlazeMeter documents generator functions for examples such as relative dates, plausible names, and fake but valid credit-card numbers. Those are product-specific capabilities, not a guarantee that generated data is appropriate for your application or that a workflow meets a privacy law or security requirement. Validate your own fixture and handling rules.

4. Preview the template or generate a document

Option A: Use a builder preview

1. Open the template’s sample-data or payload editor.
2. Paste a fixture that matches the production payload’s structure.
3. Confirm the preview populates each expected field, image, and repeated section.
4. Switch to the long-content and empty-state variants.
5. Save the useful fixture with the template when the tool supports it.

PDFMonkey documents a payload editor where test JSON populates text, images, and loops in the preview canvas. It also says that test JSON is saved with the template and uses the same structure as the API or dashboard payload. That shared structure is useful: the fixture can exercise the shape your application will send instead of a separate preview-only model.

Option B: Generate through the same API path as the application

When your generator has an API but no useful live preview, submit the fixture through the application’s normal generation path. Adobe’s getting-started guide describes authoring a Word template, preparing JSON, and invoking its Document Generation API to create a PDF or Word output. The endpoint, authentication, and request schema are specific to the configured service, so use its current API documentation rather than guessing them.

1. Load the fixture from a file in a development or staging environment.
2. Send it using the same field mapping and template identifier as the application.
3. Save the returned document to a local review location.
4. Repeat for each fixture variant and compare the output pages.

Option C: Populate fields in an existing PDF

If your source is a fillable PDF, map fixture values to its existing form fields and verify the result in the document. This is not equivalent to merging JSON into a designed template: the field names and relationships in the PDF define the target. For multi-column source data, preserve row relationships so a value from one record does not end up beside another record’s value.

5. Inspect the rendered PDF systematically

A successful API response only shows that a file was produced. It does not prove that the page is readable or that dynamic values landed in the right place. Review every fixture output at normal viewing size and, for layout-sensitive documents, at print size too.

What to inspect	Questions to ask
Text and formatting	Are values present, readable, correctly formatted, and wrapped without clipping?
Optional values	Does missing or empty data leave a clean gap, a suitable label, or the intended empty-state message?
Repeated sections	Do zero items hide the section cleanly? Do multiple items repeat in order without overlap?
Images	Did the image load, preserve its aspect ratio, and fit its allotted area?
Pagination	Are headings separated from the content they introduce? Are tables split sensibly? Do headers, footers, and page numbers remain correct?
Consistency	Do displayed totals, dates, labels, and repeated identifiers agree with one another?

Keep a record of which fixture produced each reviewed file. A clear filename such as invoice-long-notes.pdf makes it easier to discuss and reproduce a visual defect than an anonymous generated file.

6. Keep fixtures repeatable as templates change

Retain a small set of deterministic fixtures beside the template or in the application’s test assets. When someone edits the template, render the same cases again and inspect the resulting PDFs. This practical regression workflow is not a universal requirement stated by the vendors, but it follows from the benefit of replaying the same sample data after a change.

• Use stable values and URLs so the same fixture does not change meaning between reviews.
• Give each fixture a purpose, such as typical, long-text, no-items, or missing-logo.
• When the payload contract changes, update the fixture and the template together.
• Keep test data synthetic or safely mocked where it could expose personal or confidential information.
• For high-impact documents, include human review of rendered output; a successful generation call cannot catch every visual defect.

Or skip the browser setup

If your PDF workflow needs a screenshot of a rendered web page, ScreenshotNeo can return a screenshot or PDF from one GET request. It is a website screenshot API and MCP server from ScreenshotNeo. The call below captures a page as WebP; see the ScreenshotNeo API documentation for request options.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

Cookie banners, newsletter popups, and chat widgets are removed before the shot. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and the response identifies the page verdict and billing status in headers. Its MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

Sign up free for 1,000 screenshots a month, with no card required.

Troubleshooting

Symptom	Likely cause	What to check or change
A dynamic value is blank	The fixture key, nesting, or type does not match the template contract.	Compare the exact payload path with the template binding. Check missing, null, and empty-string behavior separately.
A repeated table has no rows	The collection is missing, empty, or named differently from the loop’s expected array.	Check the array key and item field names. Test zero, one, and several entries.
Long content overlaps or is clipped	The template has a fixed-height area, constrained table row, or unsuitable wrapping behavior.	Render a long-content fixture. Adjust the template’s wrapping, sizing, or page-break behavior and regenerate.
An image is missing	The URL is inaccessible to the renderer, malformed, or points to unavailable content.	Use a stable test image URL supported by the workflow, then test the missing-image case if it can happen in production.
There is an unexpected blank page	A page break, overflow, or empty repeated section changes pagination.	Compare the typical and boundary fixtures. Inspect the content immediately before the blank page and the template’s break rules.
Preview looks right but the generated output differs	The preview and production request may use different data, template versions, or execution paths.	Send the same saved fixture through the production-like generation path and confirm the selected template and payload version.
Numbers or dates look wrong	The source type or formatting assumption differs from what the template expects.	Check whether the payload sends a number or formatted string and standardize timezone, locale, rounding, and display rules.

Performance, reliability, and cost notes

Sample data helps prevent avoidable rework by exposing layout defects before real documents are generated in volume. It does not establish how fast a particular renderer is or what a service will cost; those depend on the selected tool, its current plan, document size, and usage. The research sources do not provide comparable current pricing or performance figures.

Keep fixtures modest while iterating, then include realistic maximum-size cases to expose long tables and pagination behavior. If generation depends on remote images, make sure the test environment can reach them and remember that a changing remote asset can make a preview less repeatable. For reliability, preserve the input fixture and the resulting output together when diagnosing a defect; that lets you distinguish a bad payload from a template rendering problem.

Do not infer privacy or compliance guarantees from the fact that a fixture is synthetic. Decide what data may enter each environment, who can view saved previews, and whether URLs or generated documents expose sensitive information. Use product documentation and your own organization’s requirements for those decisions.

Frequently asked questions

Can I use production data as a fixture?

Prefer fabricated or appropriately mocked values when real records contain personal or confidential information. If a production-shaped payload is needed to reproduce a defect, follow your organization’s data-handling rules and remove values that are not needed for the reproduction.

Should a fixture include calculated totals?

Match the application contract. If the application sends totals, include them and keep them consistent with the line items for normal cases. If the template calculates them, test the inputs and the template’s displayed result.

Is a PDF form the same as a document template?

No. A form workflow fills fields in an existing PDF. A document-generation workflow merges data into a designed template to create a document. Identify which one your application uses before choosing a test-data method.

How many fixtures do I need?

There is no universal count. Start with a typical case and add a fixture for each distinct behavior that can alter content or layout, such as long text, empty collections, missing images, and boundary values.