Data-Driven Testing

Testing with a single set of data (like "user1") is a good start, but it doesn't prove your API is robust. What happens if the username has spaces? What if it's 100 characters long? What if the email is invalid?

Data-Driven Testing (DDT) allows you to run the same test scenario multiple times, using a different set of data from an external file (CSV or JSON) for each iteration.

What is Data-Driven Testing?

Instead of hardcoding values like "username": "testuser", you use variables like "username": "{{username}}". You then feed a table of data into the test runner.

Why use it?

Coverage: Test 100 edge cases in seconds.

Efficiency: Write the test logic once, run it endlessly.

Separation: Keep your test logic separate from your test data.

Step 1: Prepare Your Data

Apidog supports CSV and JSON formats. CSV is usually easiest to manage in Excel or Google Sheets.

Example CSV (`users.csv`)

Create a file with headers matching your variable names:

username,email,password,expected_status
valid_user,valid@email.com,Pass123!,201
short_pass,valid2@email.com,123,400
bad_email,notanapemail,Pass123!,400
long_user,user_with_very_long_name_check_limits@email.com,Pass123!,201

Note: The headers (username, email) will automatically become variable names in Apidog.

Step 2: Configure the Test Scenario

Open your Test Scenario (e.g., "User Registration").

In your API Request (POST /users), replace the hardcoded values with variables:

Body:

{
  "username": "{{username}}",
  "email": "{{email}}",
  "password": "{{password}}"
}

Update Assertions: Since the expected result changes (some pass, some fail), make your assertion dynamic too!

Assertion: Response.status.code Equals {{expected_status}}

Step 3: Import Data and Run

Now, let's connect the data file to the test runner.

Click the Run button for your scenario.

In the run settings, look for the Test Data section.

Click Import and select your users.csv file.

Preview: Apidog will show you the preview of loaded data rows.

Run: Click Run.

See details: Data-Driven Testing

Step 4: Analyze Results

Apidog will execute the scenario once for every row in your CSV file. In our example, Iteration 1 uses valid_user and expects a 201, which should pass. Iteration 2 uses short_pass, which is invalid. Since we configured the expected status to be 400, the test passes because the API correctly rejected the bad data.

The report groups these by iteration, allowing you to see exactly which data row caused a failure.

Best Practices

Include Expected Results: As seen in the example (expected_status), put your success criteria IN the data file. This allows one test script to handle both positive and negative tests.

Keep Data Small: Don't upload a 1GB CSV. Stick to key representative cases.

Random vs. Sequential: Apidog usually processes rows sequentially (Row 1, then Row 2). This is deterministic and recommended.

Key Takeaways

Externalize test data for scalability

Use CSV/JSON files for data driving

Apply data-driven approaches for batch testing

What's Next

We've covered functional testing, integration logic, and data coverage. But does your API scale? Can it handle 1,000 users at once?

In the next chapter, we'll dive into Performance Testing using Apidog.

Continue with → Performance Testing

What is Data-Driven Testing?#

Step 1: Prepare Your Data#

Example CSV (users.csv)#

Step 2: Configure the Test Scenario#

Step 3: Import Data and Run#

Step 4: Analyze Results#

Best Practices#

Key Takeaways#

What's Next#