Contica Test Tool

Negative tests for Contica integrations, built and run from VS Code.

Most integration tests only check the happy path: a good message goes in, the right result comes out. Production breaks on everything else. A required field is missing, a code isn't in the allowed list, a value is too long. Writing a broken message for every rule by hand is slow, so it usually doesn't happen.

This extension does it for you. It reads the integration's real files, works out what should fail and why, lets you approve the plan, builds the broken messages, sends them to the Logic App, and shows you what happened.

Who it's for: testers and integration engineers. You don't need to be a developer.

Test environments only. The Test step sends deliberately broken messages to real Azure resources. Point it at test or development resources, never production. The safest setup: give testers Azure roles on test resources only.

---

Why negative tests?

An integration moves messages between systems, for example orders from a webshop into an ERP. Testing usually proves it works when everything is right. But real messages are often wrong: a field is empty, a date has the wrong format, a product code doesn't exist.

The question that matters is: what does the integration do then? Does it reject the message with a clear error? Send it to an error queue? Or does it quietly pass bad data on to the next system?

A negative test answers that. It takes a real, valid message, breaks one thing on purpose, sends it, and checks that the integration reacts the way it should. One test per rule: one for the missing customer number, one for the too-long product name, one for the unknown country code.

Why they rarely get done

Negative tests are hard work, so they often get skipped:

• Finding the rules. You first have to read the schema, the mapping and the workflow to know what should fail.
• Making the broken messages. You can't ask the source system to send a broken order on demand. So someone has to hand-craft or mock each bad file, one per rule, without making a mistake that breaks something else.
• Running them in Azure. Each message has to reach the right Logic App: find the trigger URL, or send it to the right Service Bus queue or storage container. Then dig through the run history to see what actually happened.

This tool does all three for you. It finds the rules, proposes the tests and explains each one. It builds the broken messages from a real example. It sends them to your test environment and puts what happened next to what was expected. You stay in charge: you approve the plan and judge the results.

Words you'll see

Word	What it means
Integration	One connection between systems, with an ID like INT0542.
Entity	One message flow inside an integration, like INT0542.i001 (inbound) or INT0542.o001 (outbound). Tests are made per entity.
Bundle	A folder with the entity's real files: example messages, schemas, mappings, documentation and workflow. It's what the tool reads.
Manifest	manifest.json, a small file in the bundle that says what each file is.
Plan	The list of tests the tool proposes. You review and approve it.
Gap	Something the tool couldn't prove from the bundle, so it asks you instead of guessing.
Test pack	The broken messages, one per test, each with a short note on what it breaks and what should happen.
Environment	A connection to a shared bundle repository, for example Test or QA, so your team works on the same bundles.

---

What you need

1. VS Code 1.95 or later.
2. GitHub Copilot Chat, signed in. Analyse and Generate use it, and so do the short AI summaries on test results. A Claude model works best; when none is available, the tool uses another Copilot model and tells you. Without Copilot you can still browse bundles, run tests and read results.
3. A bundle you prepare: the integration's real files, collected by you from your own sources and described by a manifest.json. This is the most important part. See Preparing a bundle.
4. For the Test step only: your own Microsoft account, with a role on the Azure resources the integration uses. Tests run against Logic Apps Standard; Consumption Logic Apps aren't supported. See Access and permissions.
5. For Run locally only (Preview): the .NET 10 SDK. See Run locally.

---

The four steps

Step	What happens	Who does it
Fetch	Collect the integration's files (example messages, schemas, mappings, documentation, workflow) from your own sources, and put them in a bundle folder with a manifest. The tool doesn't fetch anything for you.	You, with your own scripts or tools
Analyse	The tool reads the bundle and proposes a test plan. Everything the AI claims is checked against the bundle.	The tool, then you review
Generate	Each test in the plan becomes a broken message, with a short note on what it breaks and what should happen.	The tool
Test	Each message is sent to the Logic App in your test environment, and the run is read back. Or, for a Logic App, run on your own computer first with Run locally. You compare what happened with what was expected.	The tool, then you review

Your data decides everything. Garbage in, garbage out. The tool only knows what's in the bundle. It can't see your systems, your Azure or your documentation unless you put them in the bundle.

• A bundle with one example and nothing else gives a thin plan, full of gaps.
• A bundle with real examples, the schemas, the mappings and the documentation gives a rich plan you can trust.
• Wrong or outdated files give wrong tests.

So spend your time on the bundle. It's the most important part of the work.

What Analyse gives you: what to test, what to watch for, and what can't be tested.

The plan you approve: each test says what it breaks and what should happen. Untick, delete or add your own.

---

How it works

  BUNDLE REPO (git)          One copy per environment (Dev / Test / QA),
  ┌──────────────────┐       so each stage can have its own files.
  │ INT0542/         │
  │   manifest.json  │
  │   schemas/       │
  │   mappings/      │
  │   examples/      │
  │   code/          │
  └────────┬─────────┘
           │ read
           ▼
  ┌──────────────────────────────────────────────────────────┐
  │ ANALYSE                                                  │
  │  Count the rules     required fields, lengths, patterns  │
  │                      and allowed values, straight from   │
  │                      the schemas. No AI.                 │
  │  Propose tests  ───► Claude, via Copilot                 │
  │  Check every claim   against the bundle. Anything it     │
  │                      can't prove becomes a gap, not a    │
  │                      test.                               │
  └───────────────────────────┬──────────────────────────────┘
                              ▼
                ┌──────────────────────────┐
                │ YOU REVIEW AND APPROVE   │  Nothing is generated
                └────────────┬─────────────┘  until you approve.
                             ▼
  ┌──────────────────────────────────────────────────────────┐
  │ GENERATE   one broken message + one short note per test  │
  └───────────────────────────┬──────────────────────────────┘
                              ▼
  ┌──────────────────────────────────────────────────────────┐
  │ TEST       send each message, read the Logic App run,    │
  │            show it next to the expected outcome          │
  └───────────────────────────┬──────────────────────────────┘
                              ▼
                results saved in the bundle repo

Everything is saved in the bundle repo, so when a colleague syncs, they see the same plan, tests and results as you.

---

Getting started

1. Install the extension from the Marketplace.
2. Connect your bundles. In the Contica Test Tool sidebar, use Add / Edit Environment to connect a bundle repository. Or set conticaTestTool.bundleDir to a folder on your computer.
3. Pick an entity in the Integrations list. One without a valid manifest.json shows greyed out and tells you what's missing.
4. Analyse. You get three tabs:
   • Summary: what was found in the bundle.
   • Plan: the proposed tests. Turn them off, delete them, or add your own.
   • Gaps: what the tool couldn't prove from the bundle, and why it matters. Confirm it, mark it not applicable, or leave it for later.
5. Approve Plan for Generation. Nothing is generated before you do.
6. Generate Test Pack. One broken message per test, each with a short note.
7. Run Test (optional). Pick the Azure resource and confirm. The tool sends each message and shows what happened next to what was expected. You decide whether each test behaved as it should.

From Copilot Chat

@tester /analyse INT0542.o009
@tester /generate INT0542.o009
@tester /test INT0542.o009

Results land in the same tabs as the sidebar. To choose the model for the sidebar, run Contica Test Tool: Choose AI Model.

Azure Data Factory integrations

You don't build these bundles by hand. Get the factory export as a zip (the factory's git folder, or the ARM template from Export ARM Template in the portal), plus the source of any custom code it runs (Function, stored procedure, notebook). Then run Contica Test Tool: Import a Data Factory export....

The import splits the integration into pieces you can test on their own, writes a bundle for each, and opens a page that explains how the integration is built. It never connects to Azure. If code is missing from the zip, it tells you which files to ask for.

---

Preparing a bundle

A bundle is a folder with an integration's real files: example messages, schemas, mappings, documentation and workflow code.

Where the files come from

The tool doesn't collect them. You do, from wherever your team keeps them, for example:

• Example messages: Service Bus traces, Logic App run inputs, recorded test payloads.
• Schemas and mappings: your source code repositories (Azure DevOps, GitHub), or the mapping documents.
• Workflow: the Logic App's workflow.json from your repository or the Azure portal.
• Documentation: your integration documentation, for example exported from Confluence.

Most teams write their own scripts to gather these files and write the manifests, so a bundle can be rebuilt the same way every time. Any tool works, as long as the result is the folder and manifests described below. (Azure Data Factory integrations are the exception: the Data Factory import builds the bundle for you.)

Let Claude Code write the script

If you use Claude Code, the bundle builder skill does this with you. Tell it where your code, documentation, mapping spreadsheets and test messages are. It tells you what access each source needs, then writes one script that fetches everything and writes the manifests. When your sources change, run the script again. It also comes with a checker that reads a bundle the way this tool does and tells you, per entity, whether Run in Azure and Run locally will work, and it explains what you need before your first test.

Get the bundle builder skill

Keep bundles up to date. When the integration changes, update its bundle, and the tool shows which analyses are now out of date.

A manifest (manifest.json) is a small file you write next to them. It tells the tool what each file is: "this is a happy-path example", "this is the source schema", "this is the mapping". The tool only reads files the manifest lists, so folder names are up to you.

Every integration has two levels, and each has its own manifest:

INT0542/                        one folder per integration
├── manifest.json               integration manifest: files shared by all entities
├── schemas/  mappings/  code/
│
└── INT0542.i001/               one folder per entity (one message flow)
    ├── manifest.json           entity manifest: this entity's own files
    ├── examples/               at least one real happy-path message
    ├── schemas/  mappings/  documentation/  code/

Entity IDs look like INT0542.i001 (inbound) or INT0542.o005 (outbound): a lowercase letter, then three digits.

The one thing you can't skip

At least one real happy-path example message per entity. Every test is made by breaking a real message. With no example, there's nothing to break. Take one from a Service Bus trace, a Logic App run input or a recorded test payload. Use made-up data, not real people's details.

The entity manifest

INT0542/INT0542.i001/manifest.json

Field	Required	What it is
manifestVersion	Yes	Always 1.
scope	Yes	Always "entity".
integrationId	Yes	The integration, for example "INT0542".
entityId	Yes	The entity, for example "i001".
entityFiles	Yes	The entity's files, grouped by kind (see File lists).
entityName	No	A readable name, shown in the sidebar.
direction	No	"inbound" or "outbound". Taken from the ID when left out.
format	No	"xml" or "json": the message format.
sourceSystem, targetSystem	No	Names of the systems, for your own reference.
inheritsFrom	No	Where the integration manifest is. Defaults to "../manifest.json".
jiraKey, goLiveStatus	No	For your own records. The tool keeps them but doesn't use them.
resource	No	Where tests are sent. The tool writes it when you pick the target with Discover from Azure; you don't need to write it yourself.

The integration manifest

INT0542/manifest.json

Field	Required	What it is
manifestVersion	Yes	Always 1.
scope	Yes	Always "integration".
integrationId	Yes	For example "INT0542".
entities	Yes	The entity IDs in this integration, for example ["i001", "o002"].
sharedFiles	Yes	Files every entity uses, grouped by kind. Can be empty: {}.
integrationName	No	A readable name.
jiraEpic, fetchedAt, fetchedBy	No	For your own records, for example who built the bundle and when. The tool keeps them but doesn't use them.
sourceProvenance	No	Where the bundle came from, as { "kind": "..." }. The Data Factory import sets "kind": "datafactory" and uses it to recognise its own bundles, so don't change it on imported bundles.

File lists

Inside entityFiles and sharedFiles, each kind of file is a list. All lists are optional, but every entity needs at least one example. Every item has a path (relative to the manifest), a purpose, and optionally an encoding.

List	purpose values	What it gives you
examples	happy-path, edge-case, reference, trigger-format, archived (ignored)	The messages tests are built from. Required.
schemas	source, target, canonical, shared-types	Tests for required fields, lengths, patterns and allowed values.
mappings	source-to-canonical, canonical-to-target, end-to-end, overview, archived	Tests that check the mapping is right.
endToEndMappings	Same as mappings. Each item can also have fromSystem and toSystem.	A mapping across the whole integration, from the first system to the last. Integration manifest only.
documentation	main-documentation, trigger-documentation, architecture-note, business-rules	Tests for business rules. The entity's main-documentation file (or the first in its list) is read, followed by the integration's shared main-documentation file if there is one (.md or .txt).
code	workflow-definition, connection-config, transformation, infrastructure, custom-code	Tests for workflow steps, retries and routing.
standards	error-handling, retry-policy, logic-apps-conventions, azure-functions-conventions, integration-standards	Tests for error handling and retries. Usually in the integration manifest. An entity can have its own too; when both have a file with the same name, the entity's is used.

encoding is utf-8 by default. Set utf-16-le, utf-16-be or windows-1252 for files saved that way.

A minimal bundle

The smallest bundle that works: one entity, one example.

INT0542/INT0542.i001/manifest.json

{
  "manifestVersion": 1,
  "scope": "entity",
  "integrationId": "INT0542",
  "entityId": "i001",
  "entityName": "Incoming order",
  "direction": "inbound",
  "format": "xml",
  "entityFiles": {
    "examples": [
      { "path": "examples/INT0542.i001 New order.xml", "purpose": "happy-path" }
    ]
  }
}

INT0542/manifest.json

{
  "manifestVersion": 1,
  "scope": "integration",
  "integrationId": "INT0542",
  "integrationName": "Order intake",
  "sharedFiles": {},
  "entities": ["i001"]
}

Then grow it: add the source schema ("purpose": "source"), then the mapping, then documentation. Run Analyse after each one. The plan gets richer and the list of gaps gets shorter.

Tip: put the entity ID in example and mapping file names (like above), so they're matched to the right entity.

---

Access and permissions

The tool has no identity of its own. Everything runs as you, so it can never do more than you're allowed to.

Part	Needs
Analyse, Generate, Data Factory import, AI summaries of test results	A GitHub Copilot sign-in. No Azure access.
Sharing the bundle repo (Connect, Sync)	Access to that one GitHub repository, through the Contica Test Tool Bundle Sync app.
Test	Your Microsoft account, with the roles below.

Azure roles for the Test step

Only the Test step touches Azure. Give each tester these roles on the test resources the integration uses, never at subscription level. Which rows you need depends on how the workflow is triggered:

Resource	Role	Assign it on	What the tool does with it
Logic App (Standard)	Logic Apps Standard Operator	The Logic App	Lists workflows and triggers, gets the trigger URL, reads run history. Always needed.
Service Bus (queue or topic trigger)	Azure Service Bus Data Sender	The queue or topic	Sends the test messages. Never receives, peeks or deletes.
Blob Storage (file trigger)	Storage Blob Data Contributor	The container	Uploads the test files. Never reads, lists or deletes.
Service Bus namespace or storage account	Reader	The namespace or account	Lets the picker list it, and lets the tool check it in Azure before each run. Needed for a Service Bus or Blob trigger: there is no way to type the name by hand.

An HTTP-triggered workflow only needs the first row. Analyse, Generate and the Data Factory import need no Azure access at all, and the tool never reads connection strings, access keys or SAS keys.

Why not Reader on the Logic App? Getting a trigger URL is an action, not a read, so Reader is refused. The tool asks Azure for that URL at the start of every test run and never stores it, so testers need Logic Apps Standard Operator (or the custom role below).

The exact minimum: a custom role

Logic Apps Standard Operator also allows starting, stopping and updating the Logic App, which the tool never does. If you need the exact minimum, create this role and assign it instead, on the same resources. Replace the subscription ID.

{
  "Name": "Contica Test Tool Tester",
  "Description": "Send test messages and read the results with the Contica Test Tool. Nothing else.",
  "Actions": [
    "Microsoft.Web/sites/read",
    "Microsoft.Web/sites/workflows/read",
    "Microsoft.Web/sites/hostruntime/webhooks/api/workflows/triggers/read",
    "Microsoft.Web/sites/hostruntime/webhooks/api/workflows/triggers/listCallbackUrl/action",
    "Microsoft.Web/sites/hostruntime/webhooks/api/workflows/runs/read",
    "Microsoft.Web/sites/hostruntime/webhooks/api/workflows/runs/*/read",
    "Microsoft.ServiceBus/namespaces/read",
    "Microsoft.ServiceBus/namespaces/queues/read",
    "Microsoft.ServiceBus/namespaces/topics/read",
    "Microsoft.Storage/storageAccounts/read",
    "Microsoft.Storage/storageAccounts/blobServices/containers/read"
  ],
  "NotActions": [],
  "DataActions": [
    "Microsoft.ServiceBus/*/send/action",
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write"
  ],
  "NotDataActions": [],
  "AssignableScopes": ["/subscriptions/00000000-0000-0000-0000-000000000000"]
}

Each permission matches something the tool does. Azure accepts this role as written, but try it on one test resource first: the built-in roles above are the supported setup.

Making sure tests go to the right place

Test messages are broken on purpose, so where they go matters. The target is chosen once per entity and saved in its manifest. Before anything is sent:

• You confirm the target every time. You see the Logic App, workflow, resource group, subscription and the exact queue, container or trigger. Nothing is sent until you choose Send.
• A target that doesn't match the bundle is refused. If the workflow, or what it listens on (the trigger, queue, topic and subscription, or container), isn't what the bundle describes, nothing is sent. A queue, topic or container written as @parameters('name') is read from the bundle's parameters.json. If the name comes from an app setting (@appsetting(...)), or the parameter has no plain value in parameters.json, the bundle can't say which one is right, so nothing is sent. Run locally still works for those.
• You type the name when it matters: when the target is new to you, has changed since you last confirmed it, or looks like production (prod, prd, production). If you just picked the target yourself with Discover from Azure, choosing Send is enough, unless it looks like production.
• You can lock subscriptions per environment. The Test subscriptions row under your environment in the sidebar shows which Azure subscriptions tests may send to. Click it to tick them by name. Runs against any other subscription are refused.
• Every target is checked in Azure before a test. You pick the Logic App from Azure, and before anything is sent the tool checks, with your own sign-in, that the app and workflow exist and that you can see them. If you can't, nothing is sent.
• Tests go to the workflow that receives the message. If an integration has several workflows, the tool picks the one that gets the message from outside, not a child workflow. It also warns you when that workflow, or a workflow it passes messages on to, calls a written-out web address that looks like production. Addresses that come from settings can't be seen in the bundle, so no warning doesn't prove nothing reaches production.
• Only Azure addresses are allowed, so a bundle can't send your messages or sign-in anywhere else.
• Your roles are the final safety net. With roles on test resources only, a wrong choice can't reach production.

Signing in

Azure. The first Azure action after VS Code starts asks you to sign in with your Microsoft account. It's only ever you: no fallback to the Azure CLI or other credentials on the computer. Your organisation's MFA and Conditional Access apply. Guests in another tenant set conticaTestTool.azureTenantId.

GitHub. The bundle repo is reached through the Contica Test Tool Bundle Sync app, which your organisation installs on the bundle repository only. You sign in once with a short code on github.com.

For your GitHub admin and security team: the GitHub access security brief (PDF) covers what to install, what the app can and can't do, and how to remove access.

• Two tokens. The access token is the only one that can read or write the repo, and it lasts 8 hours. The renewal token can't touch any repo: it only gets a new access token, lasts 6 months, and is replaced each time. So you stay signed in as long as you use the tool at least once every 6 months.
• No personal tokens. The tool never uses personal access tokens, your VS Code GitHub sign-in, or a GitHub login saved on the computer.
• Your own app? If your organisation registered its own GitHub App for the tool, set its Client ID in conticaTestTool.bundleRepo.githubAppClientId.
• Only through the app. A GitHub repo always goes through the app, however its address is written (https or SSH). Until you're signed in and the app can reach the repo, the tool shows none of its bundles.
• GitHub only. Bundle repos must be on GitHub: github.com, or your organisation's GitHub Enterprise address (set it in GitHub Address, together with your organisation's own app). Repos anywhere else, such as Azure DevOps, aren't supported.

Once an environment or a bundles folder is set up, the Environment group at the top of the sidebar shows which environment you are in and who you're signed in as, on GitHub and Azure, with sign-in and sign-out right there.

Where your data goes

• To the Copilot model you choose: Analyse, Generate and the Data Factory import send the bundle files they work on, under your Copilot account and your organisation's Copilot policies.
• To Copilot, for the AI summaries on test results: after a run, the tool picks a fast Claude model in Copilot by itself, Sonnet first. It sends one request with a few lines per test. Those lines are the test's id and title, and its expected outcome. They also hold the reply code and the first 300 characters of the reply text, and whether the workflow run finished. For steps, they hold the name and error of any step that failed, and the names of skipped steps. If the run or its steps couldn't be read, they say why. For a test that couldn't run, only the reason is sent. For runs saved before 1.7.0, their one-line result is sent instead of the reply and steps. The bundle files are never sent.
• Checked for personal data first. Before each AI request and each Sync, the tool looks on your computer for real email addresses, Nordic identity numbers, card numbers, IBANs, international phone numbers, and personal fields such as names, addresses and dates of birth. Placeholders like Test or John Doe are fine. If it finds something, it shows you and sends nothing until you decide. It can't spot a real name in a field called something general like Value, so use made-up data in examples.
• To Azure: only the test messages, to the resources you picked. Run locally sends nothing to Azure.
• Keys and passwords are hidden. Passwords in connection strings, access keys, signatures, tokens and private keys are replaced by **** before anything goes to the AI model, and when a Data Factory export is imported. A test never needs them.
• To GitHub: the bundle repo, when you Sync. Sync won't push a change that adds a password, access key, signature, token or private key.
• Nothing is sent to Contica.

---

Environments

An environment is a named connection to a bundle repo, for example Dev, Test or QA. Each one is its own copy on your computer, so the stages never mix. Add / Edit Environment creates one, Switch Environment changes the active one.

Under each environment in the sidebar, the Test subscriptions row shows which Azure subscriptions tests may send to: the subscription's name, how many (hover to see the names), or Any subscription in yellow when there is no limit. Click it to change the list for that environment: tick the subscriptions you want and choose OK. Unticking all removes the environment's own list: if your team set a shared list for all environments, that one applies instead; otherwise there is no limit, and the tool asks you first.

Add / Edit Environment asks the same question as its last step:

• Choose subscriptions: tick the ones you want, by name. Sending anywhere else is blocked, and the resource picker only offers these.
• No restriction: tests may send to any subscription your account can reach.
• Keep the current setting: shown when the environment already has a limit.

If your team set conticaTestTool.allowedSubscriptions for all environments, an environment without its own choice uses that list, and you'll see Use the shared setting instead of No restriction.

Removing a limit always asks you first. If the environment allows a subscription your account can't see, it stays allowed.

---

Settings

All under conticaTestTool.*.

Setting	What it does
bundleDir	A folder of bundles on your computer. Choose Switch Environment, then Use a local bundles folder… to use it; nothing is synced then.
environments	Your environments. Managed by Add / Edit and Switch Environment. Each can have allowedSubscriptions and its own azureTenantId.
activeEnvironment	The active environment. Set by Switch Environment.
bundleRepo.githubAppClientId	Empty means the Contica Test Tool Bundle Sync app. Set it only if your organisation uses its own app.
allowedSubscriptions	Subscriptions the Test step may send to, when the environment has none of its own.
azureTenantId	The Microsoft tenant to sign in to, when the environment has none of its own. Leave empty for your home tenant.
test.runWaitSeconds	How long the Test step waits for each workflow run to show up in Azure (10 to 600 seconds, 60 by default). Raise it for slow workflows.

---

Reading test results

Every test that ran comes back as Needs review, with what happened next to what was expected:

• What happened: whether the run succeeded or failed, which step failed, and its error. This is read from the Logic App run itself, not just the first reply.
• What was expected: the plan's expected outcome.

The tool doesn't mark tests as passed or failed. Expected outcomes are written in plain words ("rejected at Validate_GTIN"), and a tool can't reliably check plain words against a run. So you compare and decide. Open the run in the Azure portal when you need the full output.

Error means the test couldn't be sent or read back. Skipped means it had no test message, for example because generating it failed.

Ran it both ways? For a Logic App you can run the same tests in Azure and on your computer. The Test tab then shows the two runs side by side: each test says whether both runs gave the same reply, and an open test shows what happened in each. Where they differ, the tool doesn't guess why. It only lists what the local run couldn't check. If the tests were generated again between the two runs, they aren't put side by side.

---

Run locally (Preview)

For a Logic Apps Standard integration, the Test tab also has Run locally. It runs the same test messages through the workflow on your own computer, before anything goes near Azure.

• Nothing is sent anywhere. Steps that would call another system or run separate code, such as a Service Bus send, an HTTP call, an Azure Function, a child workflow or inline C# or PowerShell, are faked as successful. Everything else runs for real: the schema checks, conditions, loops, replies, and your Liquid and XSLT maps when they're in the bundle.
• You see every step. Each result lists what every step of the workflow did, which steps were faked, and what the run couldn't check.
• You still decide. Results come back as Needs review, as in Azure.
• It's a first check, not the last one. It doesn't include the deployed app, its settings, its connections or the real systems it talks to. Run in Azure as well before you sign off.

What you need: the .NET 10 SDK (choose "SDK", not "Runtime"). The first run sets things up, which takes a minute or two.

Not yet supported: workflows that start on Blob Storage or a schedule, workflows with more than one trigger, AI agent steps, integration account and EDI steps, and bundles with more than one receiving workflow. For those, the button says why, and Run in Azure works as before.

Built on Microsoft's Azure Logic Apps Automated Test SDK. It's downloaded from nuget.org on your computer the first time; the tool doesn't ship it. The Contica Test Tool works alongside Microsoft's Logic Apps tools: use those to build workflows and write unit tests, and use this to get tests made for you from the integration's own files, whether you're a tester or a developer.

---

Made by

Built at Contica by Yamen Alnsierat and Ahmed Bayoumy.

Support

Free to install and use under a proprietary licence. The source code isn't public. For questions or problems, contact your Contica representative.