Test Exchange Packages: Compare What Must Survive

A useful exchange test is a small, representative experiment with a stated purpose. It includes the dependencies and context that the real handoff needs, records the source baseline, exercises the real transfer direction, and compares the information layers that the recipient cannot afford to lose.

Choose representative assets

Select assets because they exercise risk, not because they are easy to open. A package may include:

• a part with the geometry types, tolerances, or topology that matter to the downstream operation;
• an assembly with repeated instances, configurations, external references, and meaningful identities;
• drawings, PMI, materials, classifications, spatial placements, textures, buffers, or manufacturing attributes that are part of the acceptance case;
• a known dependency or composed representation whose relocation behavior must be tested; and
• an intentionally difficult but realistic case, such as a large assembly, a variant, or a model with a known conversion boundary.

Keep the test population small enough to understand. A convenient single part can show that a route works for that part while saying nothing about assemblies, configuration behavior, dependency closure, scale, performance, or the recipient’s real task.

NIST’s PMI testing project is a useful example of deliberate test fixtures. It separates test-case definitions, CAD models generated from those definitions, and verification and validation results. Its combined and fully toleranced cases exercise different PMI intentions. The project is historical and bounded to particular standards, CAD releases, validation software, and fixtures; it should inform test design, not rank current products.

Capture the baseline first

Before transfer, record the evidence against which the destination will be compared:

Baseline item	Record
Purpose and acceptance case	The downstream task, required layers, permitted loss, and failure disposition.
Source identity	File or package identifier, configuration, revision, and any external references.
Environment	Source application, release, operating context where material, and export settings.
Representation	Format, schema/profile, extensions, units, coordinates, and translator context.
Measurable properties	Selected geometry, assembly, PMI, attribute, annotation, or tessellated values and their units.
Inspectable properties	Required names, identities, relationships, views, classifications, resources, and expected counts.
Dependencies	Referenced files, assets, layers, payloads, resolver context, and companion documents.
Intentional exclusions	Layers that are not being tested or are allowed to transform.

The baseline should be understandable without opening the source file. A screenshot can preserve visual context, but it should not replace a structured value or a test of the operation that matters.

Exercise the real direction

Test the same direction and settings that the recipient will use. Do not validate an export and then assume that an import, reference, or return path has the same behavior. Preserve the received package before repair and record any preprocessing, conversion, flattening, re-linking, or manual reconstruction.

For a STEP example, the NIST Analyzer reports entity and attribute information, semantic and graphic PMI, validation properties, and basic syntax problems. Its syntax checker can flag issues such as missing or extra attributes and unresolved entity references. Those checks help identify structural or import risks; they do not replace the destination-task comparison.

For an IFC package, a conformity preflight can be staged separately from the project check: buildingSMART’s IFC Validation Service describes checks for STEP syntax, the IFC schema, normative IFC rules, and non-normative industry practices. Project-specific rules and geometric visualization are outside that service, so keep them in the layer and task comparisons that follow.

Compare the layers separately

Use a comparison set that matches the acceptance case:

Comparison	Useful question
File or schema structure	Can the payload be parsed, and does it meet the selected structural or profile conditions?
Geometry	Do selected dimensions, area, volume, centroid, bounds, or local deviations agree within the agreed method and tolerance?
Topology and tessellation	Are closure, orientation, manifold conditions, mesh resolution, or other task-specific properties acceptable?
Structure and identity	Are required instances, configurations, names, references, and relationships present and resolved?
PMI and documentation	Are the selected semantic and graphic representations present, interpretable, and usable?
Spatial context	Do units, axes, frames, transforms, placements, and coordinates produce the expected result?
Visual resources	Do materials, images, buffers, cameras, and variants load in the target context?
Downstream operation	Can the recipient perform the named edit, coordination, measurement, machining, print preparation, inspection, or viewing task?

NIST’s validation-property guide describes a direction-specific comparison: write selected properties to a STEP file from the originating CAD system, import it, compute the same properties in the receiving system, compare the values, and treat the geometric exchange as validated only when the selected values fall within an agreed tolerance. This validates the compared properties, not the entire file.

Include dependencies in the test

Test the package as delivered, not only the primary file from a convenient source directory. Move it to a clean test location or recipient-like environment and record whether every required resource resolves. A package that works only because it can still see the sender’s local path has not demonstrated reproducible delivery.

The test should expose what is embedded and what remains external. For example, glTF .gltf assets can reference external buffers and images, while a .glb packs JSON and one buffer but may still reference external resources. In OpenUSD, flattening or packaging can change composition and path behavior. These are representation-specific examples, so use the same dependency inspection for the actual route.

Retain the outcome

Keep the source baseline, received package, tool and version context, reports, comparison values, screenshots where useful, unresolved warnings, repair actions, and the final decision together. State exactly what passed and what was not tested.

When a route changes, turn the relevant checks into regression tests. A test set should grow from observed risk: changed translator behavior, a new profile, a new dependency type, a changed model view, a revised configuration, or a previously missed information layer. It does not need to become a universal suite.

buildingSMART’s IFC certification model illustrates the value of combining test cases at different scales and complexity with automatic routines, regression tests, manual verification, issue tracking, and final reporting. Its scope remains the selected IFC requirements and Model View Definition; reuse the testing pattern without presenting it as a universal CAD acceptance recipe.

The 3MF Consortium provides another bounded test-planning example. Its published conformance suites are organized around explicit Core-and-extension combinations and pinned specification versions. Select the suite and version that match the package, then record the implementation result separately; suite coverage alone does not establish that an exporter, importer, printer, or production task accepts the data.

Key points

• Choose fixtures that represent the real failure modes and downstream task.
• Capture the source baseline, context, dependencies, and exclusions before transfer.
• Compare geometry, structure, semantics, spatial context, resources, and task behavior as separate questions.
• Test relocation and the real delivery direction.
• Retain evidence and repeat affected checks when the route changes.