Write a field contract before connecting the output
Read the guide →Guide preview
Define names, types, missing values and acceptance rules before automating a destination.
Check the output
Make accepted data explicit.
Test missing fields, row pairing and layout changes before relying on a result.
Test missing fields, row pairing and layout changes before relying on a result.
5 practical guides
Choose the question closest to yours.
New to the topic? Begin with the first guide. Otherwise, go straight to the question you need to answer.
Build a small acceptance pack for a document parser
Read the guide →Guide preview
Use expected answers and awkward cases, not just a successful demonstration document.
Review line items without trusting the row count alone
Read the guide →Guide preview
Check row identity and field pairing as well as the number of extracted lines.
Missing, unreadable and zero are different results
Read the guide →Guide preview
Preserve absence explicitly instead of filling required fields with plausible values.
Test a layout change without erasing the old result
Read the guide →Guide preview
Keep versioned samples so a fix for the new layout does not quietly break the old one.
Write the answer before checking the output.
A green processing status cannot tell you whether a quantity belongs to the correct item. Define required fields, expected rows and missing-value behavior before testing a method. Keep the source available so a reviewer can resolve a mismatch.
Use the fictional acceptance example to learn the rule, then create an authorized case pack appropriate to your own work. Do not treat matching two teaching rows as evidence of a vendor’s accuracy.
Define the field contract →