Skip to content

HTTP Request Integration Tests

Overview

An HTTP request integration test is a saved HTTP request that Martini Designer runs as a test from Test Explorer, using the request's own test script to check the response it gets back. Unlike a workflow test, which invokes a workflow directly and asserts on its internal output, an HTTP request test calls a deployed API operation end-to-end over HTTP. That makes it a contract-level check: it confirms the operation actually accepts the requests and returns the responses — status codes, headers, body shape — that callers expect, rather than verifying the logic behind the operation, whether that's a workflow, a service, a Groovy function, or any other handler.

What You Will Learn

  • How Martini identifies and collects HTTP request integration tests from your workspace
  • The recommended way to organize test requests alongside the APIs they cover
  • How a test's pass or fail outcome is determined
  • How to create a new HTTP request integration test, including with the Designer agent

Identifying and Collecting Test Requests

Martini Designer recognizes an HTTP request as a test using a filename contract, the same way it does for workflow tests: any saved request whose filename ends with Test.request — for example, PlaceOrderTest.request — is collected as an HTTP request integration test and listed under HTTP Request Tests in the Test Explorer. A request saved without that suffix is an ordinary request and is never collected as a test.

Test requests are collected only from the current workspace's requests directory. User-scoped requests — those available across all your workspaces rather than saved to a specific one — are never included, even if their filename ends with Test.request.

As described in Automatic Test Discovery, Test Explorer's tree updates automatically whenever a request test is created, deleted, moved, or renamed, so newly saved or renamed requests appear without a manual refresh.

Skipping a Request Test

To keep a test visible in Test Explorer without sending its request when its directory or the whole workspace is run, name the file with a SkipTest.request suffix instead — for example, PlaceOrderSkipTest.request. Skipped requests still appear in test runs and are marked skipped, as described in Test Runs.

Martini doesn't enforce any particular folder layout for test requests — they can live anywhere under your workspace's requests directory. As a convention, group the test requests for an operation in a directory named after the API they exercise. This keeps related tests together in the Test Explorer tree and makes it easy to run every test for a given API in one action, as described in Running and Locating Tests from the Tree.

How Pass or Fail Is Determined

An HTTP request integration test doesn't have its own separate pass/fail flag — its outcome is derived entirely from the request's test script, the same script you'd use to validate the request manually in the HTTP Request Editor. When the test runs:

  • The request is sent, and its test script executes against the response, producing one or more individual test case results.
  • If every test case in the script passes, the request test as a whole is marked passed.
  • If at least one test case in the script fails, the request test as a whole is marked failed, regardless of how many other cases passed.

For how these results are displayed — including the per-case breakdown on the Results tab — see Reading Results.

Creating an HTTP Request Test

There's no dedicated wizard for HTTP request integration tests. Any HTTP request becomes a test the moment it's saved as a workspace request file with a name ending in Test.request:

  1. Create a new HTTP request in the HTTP Client view, or open an existing one you want to turn into a test.
  2. Configure the request's method, URL, headers, and body as needed to call the target API operation, as described in Creating Requests.
  3. Save the request to a directory under your workspace's requests directory, using a filename that ends in Test.request — for example, GetOrderTest.request.

Expected result: The request appears under the HTTP Request Tests root node in Test Explorer, grouped by the directory you saved it in.

Once the request is saved as a test, add assertions to it on the Tests tab exactly as you would for any other request — see HTTP Request Tests for how to write martini.test() blocks with Chai's expect and assert styles. Those assertions are what Test Explorer uses to determine the pass or fail outcome described above.

Generating a Test with the Designer Agent

As an alternative to building a test request by hand, you can ask the Designer agent in the AI Chat view to generate an HTTP request test for you — describe the API operation and the behavior you want to verify, and the agent produces a saved request with a Test.request name and an accompanying test script. Review the generated request and its assertions before relying on it, the same way you would review any AI-generated test script.

Helpful Resources