Test Case Loader
Overview
The Test Case Loader lets you create many test cases at once from a single ZIP archive, instead of building each test case by hand. This is the fastest way to bring an existing library of message files — for example, sample documents exported from another system — into Int4 Suite.
Each test case is built from payloads: an input (the source document or message that enters the flow) and, usually, one or more expected outputs (what the flow should produce). Normally the suite captures these from a connected system using a reference document number; the loader is the alternative for when you already hold the documents as files. The expected output you load becomes the reference baseline — the recorded "before" that every later run compares its fresh result against — so loading a curated set of input/output pairs is, in effect, recording the expected behaviour of a flow in bulk.
You upload a ZIP archive, then describe which files inside it are inputs and which are their matching outputs using simple file-name patterns. The loader pairs each input file with its outputs, mirrors the folder layout inside the archive under a target folder you choose, and creates one test case per matched input. Input files become the source payloads of each test case; output files become either the expected payloads on the same test case or separate child test cases, depending on the options you pick.
Before committing to a run, you can preview the pairings: the loader shows you exactly which files would be matched, how they would be paired, and what the resulting folder and test-case structure would look like — all without creating anything. You can adjust your patterns and re-preview as many times as needed. When the result looks right, you run the job. Runs happen in the background, so you can keep working while a large archive is processed, and you can watch progress and results in the load history on the same screen.
If your license includes the AI assistant, the loader can also suggest matching input/output patterns for you, based on the file names it finds in your archive — useful when you are not sure how to write the patterns yourself.
Tasks
How to load test cases from a ZIP archive
- Open the Test Case Loader screen.
- In the Source section, under ZIP archive, select your
.zipfile. Only ZIP archives up to 100 MB are accepted. - Enter the Input file pattern — a pattern that matches the names of the files you want to turn into test case inputs (for example,
^IN_(\d+)\.xml$). - Optionally enter the Output file pattern — a pattern that matches each input's expected-output files. You can reuse pieces captured from the input pattern with
$1,$2, … back-references (for example,^OUT_$1\.xml$pairsOUT_42.xmlwithIN_42.xml). - In the Test Case Creation Parameters section, choose the Target folder the test cases will be created under, and the Automation object that defines the shape of each test case.
- Adjust the creation and execution options to taste (see Field reference).
- Click Preview to check the pairings, or Execute to start the run directly.
The Preview and Execute buttons stay disabled until you have selected an archive, a target folder, an automation object, and entered an input pattern.
How to preview the matches before running
- Fill in the archive, target folder, automation object, and input pattern as above.
- Click Preview. A preview window opens showing a tree of the folders, test cases, inputs, and outputs that would be created — nothing is created yet.
- The top of the preview shows the counts: total entries in the archive, matched inputs, paired outputs, and any inputs skipped because they had no matching outputs.
- To try different patterns without closing the window, edit the Input file pattern and Output file pattern fields in the preview and click Refresh preview.
- Use Expand all / Collapse all to inspect the tree.
- When the result looks right, click Run to start the run, or Cancel job to discard this draft and start over.
The preview is capped for display — it shows at most the first batch of matched inputs (and a limited number of outputs per input). A banner appears when the list is truncated; the actual run still processes every matched file.
How to let the assistant suggest patterns
- Run a preview first so the loader has read the file names from your archive.
- In the preview window, open the suggestions button (Suggest input/output regex pair, marked with a sparkle).
- The assistant returns up to five suggested input/output pattern pairs, each with a short explanation. Pick one to fill the pattern fields, then click Refresh preview to see the matches.
This feature requires a license that includes the AI assistant. If preview has not been run yet, the suggestions button stays disabled with the hint Run preview first to enable suggestions..
How to review past loads
- Scroll to the Recent loads section at the bottom of the screen.
- Use the search box and status filter to find a specific load.
- Click any row to open its details, including the final counts, any error message, and the step-by-step log of what the job did.
- To remove a load that is not currently running, use the Delete action; this also frees the stored archive.
Field reference
| Field | Description |
|---|---|
| ZIP archive | The ZIP archive containing your input and output files. Maximum 100 MB. Required. |
| Input file pattern | File-name pattern selecting which files in the archive become test case inputs. Capture groups (the parts in parentheses) can be reused in the output pattern. Required. |
| Output file pattern | Optional file-name pattern selecting each input's expected-output files. Supports $1…$N back-references filled from the input pattern's capture groups. Leave empty if there are no separate output files. |
| Target folder | The folder under which the loader recreates the archive's folder layout and places the new test cases. Required. The folder also determines the project scope and system environment the test cases inherit. |
| Automation object | The automation object assigned to every created test case. It defines the test's shape — which payload roles apply and which platform the test runs against. Required. |
| Save input also as expected payload | When on, each input file is attached both as the source payload and as an expected payload of the same test case. |
| Output handling | How matched output files are handled: Add as expected payloads on the parent test case attaches them as expected payloads on the same test case; Create a separate child test case for each output creates a separate child test case for each output. |
| Output automation object | Shown only when outputs become separate child test cases. The automation object assigned to those child test cases. |
| (unlocalised: skip_inputs_without_outputs — label comes from the schema metadata, not the testCase namespace) | When on, input files that have no matching output are skipped instead of becoming input-only test cases. |
| Test run (no test cases created) | When on, the loader performs the full analysis but does not create any test cases — a safe rehearsal of the run. |
Tips & edge cases
- Inputs and outputs map onto the test's payloads. The files you match as inputs become each test case's source payload, and the matched outputs become its expected payloads — the reference baseline a run is checked against. Loading an input on its own gives you a test case with no recorded "expected" to compare to, so pair your files when you want the loaded test cases to actually validate a result.
- Preview is free and repeatable. Previewing never creates test cases, and re-running the preview with adjusted patterns is the intended way to dial in your matches. Use a dry run if you want the loader to walk the whole archive end to end without persisting anything.
- Folder layout is preserved. Test cases are created under your target folder mirroring the directory structure inside the ZIP, so an organised archive yields an organised test-case hierarchy.
- Output back-references pair files precisely. The
$1…$Nplaceholders in the output pattern are filled from the corresponding capture groups in the input pattern, so each input is paired only with its own outputs rather than every output in the folder. - The AI suggestion feature is license-gated. Pattern suggestions need a license that includes the AI assistant; without it, the suggestions are simply unavailable.
- Runs happen in the background. After you start a run you are free to leave the screen; track progress and final counts in Recent loads. Open a load's details to read its step-by-step log.
- You can cancel or delete a load that is not running. Removing a finished or pending load also releases its stored archive. A load that is currently running cannot be deleted until it finishes.
Related features
Prerequisites & permissions
About permissions. Int4 Suite controls what you can see and do through roles and permission groups assigned to your user. Each role grants permissions on a specific resource (for example, Test Case, Automation Object, System Under Test) at one of four levels: Read, Write, Delete, or Execute. Some permissions are further narrowed by project scope, so you may have access to one part of the system but not another.
If a button is disabled or a list comes back empty, missing permissions are the most likely cause. Ask an administrator to review your role assignments, or check IAM → Users if you have the User: Read permission.
To use the Test Case Loader you need at minimum Folder: Write on the target folder, so the loaded test cases can be created there. Additional permissions apply to the rest of the workflow:
- Automation Object: Read — required on each automation object you assign to the loaded test cases. If you create child test cases from outputs with a different automation object, you need Read on that one too.
- The AI pattern-suggestion feature is licence-gated — it additionally requires a licence that includes the AI assistant.