Test Profile

The key to customized and efficient content validation

A test profile is our concept for chaining several validation operations seamlessly together. It enables complete message validation that checks structure, content, and business/integrity requirements at once.

You can set up test profiles for all structured data. For outgoing messages, it helps to ensure that implementation and documentation are aligned, especially after system/version updates. For incoming messages, it helps to provide an enhanced message validation as a self-service for senders (trading partners).

We encourage setting test profiles on various levels to ensure maximum interoperability:

Standardizer:

Specify requirements that are common for all users of the message format.

Industry:

Specify additional requirements that are common to the user group.

Organization:

Specify additional detailed organization-specific requirements.

Technically a test profile consists of three parts: preprocessing, test phases, and postprocessing.

1. Preprocessing

A test profile may contain several preprocessing steps to manipulate the input file before validation. Preprocessing phases include, for example, unwrapping a message envelope and pretty-printing a message to assign a unique line number for each element.

2. Test phase

Validation consists of any number of test phases. Each test phase is based on a schema (DTD or W3C XML Schema), Schematron, or a set of test assertions.

Each test phase has the "importance" parameter that specifies how detected errors will affect test execution and the final test result:

Critical:

The test phase must be passed to continue validation any further.

Mandatory:

The test phase must be passed to pass a complete validation acceptably.

Recommendation:

The test phase informs about best practices and future requirements.

Test assertion

You can specify business and technical requirements as test assertions. A test phase may contain any number of test assertions. A related test phase is marked with a "failed" status if a message does not pass a test assertion.

Test assertions are used to fulfill requirements not covered by a message schema. In other words, a schema is just a starting point for message validation, and detailed context-specific validation must be covered with test assertions.

Test assertion categories

Test assertions can be divided roughly into the following categories:

Cardinality:

A message schema usually contains many optional/conditional data elements that are mandatory in your use case. You can fill these "gaps" with test assertions.

"Invoice shall contain a due date."

Format:

You can specify simple data format constraints with a DTD/XSD schema, but its expression power is limited. For example, many identifiers contain computational check digits that a schema can't check. It's also common that a message format supports a generic method for stating an identifier where an identification scheme is provided as a qualifier (XML attribute). These data relationships you cannot check using a schema, but you will need implement those as test assertions.

"Legal business ID shall be stated using the format nnnnnnn-n, where the last number is a computational check digit."

Enumeration:

Coded data values are often used in electronic data interchange. Where a message schema may specify a long list of acceptable codes, test assertions can be used to define context-specific enumerations.

"Country code shall be specified according to ISO 3166-1 alpha 2, and valid codes are FI, DE, and FR."

Integrity:

Message schema cannot describe data dependencies and relationships. The most common integrity checks are calculation checks and comparing data values.

"A total VAT amount specified in an invoice summary shall match a sum of VAT amounts on each line."

Test assertion may include preconditions to match more complex requirements. Preconditions help to cover several scenarios with the same test profile. Learn more about test assertions.

3. Postprocessing

Postprocessing actions can be added as additional features for different purposes:

• Visualize invoice messages as a paper-like "A4 document"
• Auto-generate order response for an order message
• Deliver messages to own system to complete further inspection
• Need something else? Please ask!