Integration Testing and Data Passing

In previous unit testing, we focused on whether a single endpoint functions correctly. However, in the real world, APIs rarely exist in isolation. They often need to work together, where the output of one API becomes the input of another.

Integration Testing is the process of verifying that these components work correctly when combined. In this chapter, we will dive deep into how to build powerful integration test scenarios in Apidog and master the core skill of automated testing: Data Passing.

What is Integration Testing?

If unit testing checks "is the tire round" or "does the engine turn", then integration testing checks "can the car drive when the tire and engine are installed".

In API testing, integration testing mainly focuses on:

Component Interaction: Is data flowing smoothly between APIs?

Business Workflow: Can a complete user task (e.g., "User Register -> Login -> Purchase") be completed successfully?

State Consistency: Is the data state in the database correct after a series of operations?

Why is it Crucial?

Many bugs are only exposed when multiple components interact. For example, the registration interface might successfully return a user ID, but if the format of this ID doesn't meet the requirements of the login interface, then the user still cannot complete the business process even if individual tests for registration and login pass.

Why We Need Data Passing

In a Test Scenario, subsequent steps often rely on the results of preceding steps. This is why we need Data Passing.

Typical scenarios include:

Authentication Flow: The Login interface returns a token, and all subsequent interfaces need to carry this token in the Header.

Resource Operations: The Create User interface returns a userId, and subsequent Get, Update, and Delete user interfaces need to use this userId.

List Processing: The Get List interface returns a set of data, and subsequent steps need to extract a specific ID from it for processing.

Apidog provides two main mechanisms to achieve data passing: Retrieve Pre-step Data and Extract Variables.

Method 1: Retrieve Pre-step Data

This is a convenient feature unique to Apidog that allows you to directly "reach out" and grab data generated by previous steps without creating variables.

Use Cases

Data is used only 1-2 times in the immediate subsequent steps.

You don't want to pollute the global or environment variable list.

Building simple test links quickly.

How to Use

Suppose we want to test: Step 1 Login -> Step 2 Get User Info. Step 2 needs to use the Token returned by Step 1.

Add these two steps to the test scenario.

Click the Magic Wand icon 🪄 next to the parameter input box in Step 2.

Select Retrieve pre-step data.

In the popup interface:

Step: Select "Step 1: Login".

Result Type: Select "Response Body".

JSONPath: Enter or select the field to extract by clicking, e.g., $.token.

Click Insert, and you will see the parameter value become a dynamic reference like this: {{$.2.response.body.token}}.

Syntax Breakdown:

$: Root node

2: Step ID

response.body: Data source (Response Body)

token: Specific field path

Note: This reference method only takes effect when running the entire test scenario, because real data from preceding steps is generated only during runtime. You may not get values when debugging a single step.

Method 2: Extract Variables

This is a more general and standard method, similar to concepts in Postman. It extracts data and stores it as Variables, which can be reused in any subsequent steps via {{variable_name}}.

Use Cases

Data needs to be used repeatedly in multiple subsequent steps (e.g., Token).

Data needs to be shared across different test scenarios.

extracted data needs to be processed (e.g., via scripts) before use.

How to Use

Again, Step 1 Login -> Step 2 Get User Info.

Click Step 1: Login and go to the Post-processors tab.

Add an Extract Variable action.

Configure the extraction rules:

JSONPath: $.token (Path to extract value from response)

Variable Name: accessToken (Variable name defined by you)

Scope: Environment or Local (Temporary variable, valid only for this run). It is generally recommended to use Local variables to avoid polluting the environment.

In Step 2 and all subsequent steps, use {{accessToken}} directly in the parameter value.

See details: Pass Data Between Requests

Building an Integration Test Scenario: User Lifecycle

Let's practice integration testing by building a classic CRUD (Create, Read, Update, Delete) loop. We will build a "User Lifecycle Test" scenario.

Planning Test Steps

Step 1: Create User
       --> Extract userId to variable {{newUserId}}
       --> Extract username to variable {{newUserName}}

Step 2: Login
       --> Log in using {{newUserName}}
       --> Extract token to variable {{authToken}}

Step 3: Get User
       --> URL parameter uses {{newUserId}}
       --> Header uses {{authToken}}

Step 4: Update User
       --> URL parameter uses {{newUserId}}
       --> Body uses {{newUserName}} and other new data
       --> Header uses {{authToken}}

Step 5: Delete User
       --> URL parameter uses {{newUserId}}
       --> Header uses {{authToken}}

Step 6: Verify Deletion
       --> Try to get user {{newUserId}} again
       --> Expected result: 404 Not Found

Guide

Create New Test Scenario: Name it "User Lifecycle Integration".

Import Steps: Import the above 5 interfaces from the API list into the scenario.

Configure Step 1 (Create):

Add two variable extractions in Post-processors:

$.id -> newUserId

$.username -> newUserName

Configure Step 2 (Login):

Modify the Body parameter, setting the username value to {{newUserName}}.

Extract variable in Post-processors:

$.token -> authToken

Configure Steps 3-5:

Modify the Path parameter id in the URL, value is {{newUserId}}.

Add Authorization in the Header (if not automatically inherited), value is Bearer {{authToken}}.

Configure Step 6 (Verify):

This is a negative test. Duplicate the request from Step 3.

Modify its assertion (we will explain assertions in detail in the next chapter), expecting the status code to be 404.

Best Practices

Environment Isolation: Use randomly generated data (such as {{$randomUserName}}) to register users to avoid "User already exists" errors caused by multiple runs.

Data Cleanup (Teardown): As we did in the "User Lifecycle" case, it is best to delete the junk data generated by testing (such as new users) in the final steps of the test to keep the environment clean.

Variable Naming Conventions: Add prefixes to variables, such as TEST_USER_ID vs GLOBAL_CONFIG_ID, to distinguish between temporary variables generated during testing and global configurations.

Key Takeaways

Use Retrieve Pre-step Data for simple, one-off data passing

Use Extract Variables for reusing data across multiple steps or scenarios

Build comprehensive Integration Test Scenarios covering full business lifecycles

Validate error handling and cross-module interactions

What's Next

Now that you can string multiple requests together into a scenario, you need to ensure they are actually working as expected. Just because a request returns "200 OK" doesn't mean the data is correct.

In the next chapter, we'll learn how to use Dynamic Values to generate random data (like unique emails) to prevent duplicate key errors during testing.

Continue with → Dynamic Values

Integration Testing and Data Passing

What is Integration Testing?#

Why is it Crucial?#

Why We Need Data Passing#

Method 1: Retrieve Pre-step Data#

Use Cases#

How to Use#

Method 2: Extract Variables#

Use Cases#

How to Use#

Building an Integration Test Scenario: User Lifecycle#

Planning Test Steps#

Guide#

Best Practices#

Key Takeaways#

What's Next#

What is Integration Testing?

Why is it Crucial?

Why We Need Data Passing

Method 1: Retrieve Pre-step Data

Use Cases

How to Use

Method 2: Extract Variables

Use Cases

How to Use

Building an Integration Test Scenario: User Lifecycle

Planning Test Steps

Guide

Best Practices

Key Takeaways

What's Next