Test Data Management

Non-Production environments (Staging, QA, UAT, Pre-Production) store test data only. Live client data is stored exclusively in Production. Unlike resource promotion (which moves modules, styles, and roles from one environment to another), data does not transfer between environments during promotion.

Each environment maintains its own independent data store. Test data created in Staging does not appear in QA after promoting a module to QA. Teams must seed and manage test data separately in each environment.

What "Test Data" Means

Test data includes all submissions created through Express applications, records stored in Data Models, and any data written by modules during testing. It is separate from:

• Configuration data: Modules, services, styles, and Global Variables. These are resources promoted through the promotion pipeline.

• Live client data: Real end-user submissions in Production. Live client data is never accessible in non-Production environments.

Test data in non-Production environments should be treated as disposable. It exists to support testing and can be reset, replaced, or deleted without business impact.

Seeding Test Data

Before testing a module in a new environment, seed the test data the module expects. Common approaches:

Using the Submissions API

The Unqork Submissions API accepts JSON payloads and writes records directly to a module's data store. Use the API to create a consistent, repeatable set of test records before each testing cycle.

POST /api/v1/applications/{applicationId}/modules/{moduleId}/submissions

Script the seed data creation so the same dataset can be recreated after each reset. Store the seed scripts in version control alongside the application definition.

Using Express Applications

Run the application in QA or UAT and fill in test forms manually or with test tooling. This approach is slower but tests the full end-user , including validation and conditional logic.

Using Data Collections Import

For Data Model-backed data, use the  import in Data Collections to bulk-load test records. See Data Collections for the import process and limits (up to 10,000 rows per CSV, 1 GB file size).

Resetting Test Data

After a testing cycle, reset test data to a known state before the next cycle. Stale or inconsistent data from previous runs can cause false test failures or mask genuine issues.

Deleting Submissions

Use the Submissions API to delete test records:

DELETE /api/v1/applications/{applicationId}/modules/{moduleId}/submissions/{submissionId}

For bulk deletion, use the bulk data operations API. See Bulk Data Operations for details.

Clearing Data Collections

Data records stored through Data Models can be deleted in bulk from the Data Collections view in the Explorer, or through the Records API.

Environment Reset

If test data has become severely inconsistent, contact an Unqork representative to request a full environment data reset. This clears all submissions and records while preserving the application configuration.

Test Data by Environment

The appropriate type of test data depends on the environment's role in the promotion pipeline.

Data Isolation

Test data in one environment has no effect on other environments. A submission created in QA does not appear in UAT or Production. Environments are fully isolated at the data layer.

This isolation means teams can run destructive tests (deleting records, submitting invalid data, testing error paths) in non-Production environments without risk to live client data.

Common Mistakes

Testing with Production Data in Non-Production Environments

Never copy live client data from Production into a non-Production environment for testing. Use anonymized or synthetic data instead. Copying real data to a less-secure environment creates a data compliance risk.

Relying on Stale Data Across Test Cycles

Test data left over from previous cycles can cause tests to pass when they should fail, or fail when the module is correct. Reset test data before each cycle.

Not Seeding Data Before UAT

Business stakeholders testing in UAT need realistic data to evaluate the application. If UAT begins with an empty data store, stakeholders cannot perform meaningful acceptance testing. Coordinate with the QA team to seed UAT with a representative dataset before the UAT cycle begins.

Assuming Data Promotes with Resources

A common misunderstanding is that promoting a module also promotes the data associated with it. Data does not promote. After promoting a module to a new environment, the new environment's data store is empty (or contains whatever data was already there from previous testing).