Getting Started: Your First Test Scenario

This is where you create your first automated test. In the next 20 minutes, you'll go from zero to having a working test scenario that automatically verifies your Pet Store User API works correctly. No complex setup. No confusing concepts. Just results.

Before you start

Make sure you've completed the Developing APIs chapter and have your Pet Store User API running locally. If you haven't already, start it with:

Your API should be running at http://localhost:8000. You should see the FastAPI docs at http://localhost:8000/docs showing your six endpoints:

POST /users - User registration

POST /user/login - Login with JWT token

GET /users/{id} - Get user profile

PUT /users/{id} - Update user

DELETE /users/{id} - Delete account

POST /user/logout - Logout

Here's what we're doing:

Create a test scenario in Apidog (2 minutes)

Add a test step for user registration (5 minutes)

Run the test and see the results (3 minutes)

Let's go.

Create Your First Test Scenario

A test scenario in Apidog is like a collection of related tests. Think of it as a folder where you organize tests that belong together. For example, you might have a "User Registration Tests" scenario, or a "Complete User Lifecycle" scenario.

Open the Tests module

In Apidog, click on Tests in the left sidebar. You'll see the test scenarios list (probably empty if this is your first time).

Create a new test scenario

Click the + button next to the search bar at the top

A dialog appears asking for:

Name: Enter "User Registration Test"

Directory: Choose where to save it (or create a new folder)

Priority: Leave as default for now

Click Create

You now have an empty test scenario. It's like an empty folder waiting for tests.

Why test scenarios matter

Test scenarios help you organize tests logically. Instead of having dozens of individual tests scattered around, you group related tests together. This makes it easier to:

Find tests when you need them

Run related tests together

Share test suites with your team

Maintain tests as your API grows

Add Your First Test Step

Now let's add an actual test. We'll test the user registration endpoint (POST /users).

Add a test step

In your test scenario, click Add Step (or the + button). You'll see several options for adding requests:

Option 1: Import from endpoint spec (Recommended for beginners)

This imports the endpoint directly from your API specification. It's the easiest way to get started:

Click Import from endpoint spec

You'll see a list of all endpoints in your project

Find and select POST /users (the user registration endpoint)

Choose Manual sync mode (we'll explain this later)

Click Add

The endpoint is now added as a test step. You can see it in your scenario with all the request details already filled in from your API spec.

Option 2: Import from endpoint case

If you've already created endpoint cases (saved requests with specific parameters), you can import those instead. This is useful when you have pre-configured test data.

Option 3: Add custom request

For testing endpoints outside your project or creating custom requests, use this option. You can create any HTTP request from scratch.

Understanding the difference

Import from spec: Always matches your API design. If you update the endpoint in your API spec, you can sync the test step to match.

Import from case: Uses pre-configured parameters. Good for standardized tests with specific data.

Custom request: Maximum flexibility. Use for testing third-party APIs or edge cases.

For now, stick with "Import from endpoint spec." It's the simplest and keeps your tests aligned with your API design.

Configure Your Test Request

When you import an endpoint from the API spec, Apidog automatically fills in the request structure based on your API design. The request body, parameters, and headers are already configured according to your endpoint specification.

If you've created endpoint cases in the Designing APIs chapter, those test data will be automatically used. Otherwise, Apidog will use the default values from your API schema. You can modify the test data if needed, but for now, the auto-generated test case should work perfectly for testing your Pet Store User API.

Choose your environment

At the top right, make sure you've selected the correct environment. If your Pet Store User API is running locally, select Local Development (or whatever you named your local environment). The base URL should be http://localhost:8000 (where your FastAPI server is running).

If you haven't created a local environment yet:

Click Environments in the sidebar

Click + New Environment

Name it "Local Development"

Set Base URL to http://localhost:8000

Save and switch to this environment

Why this matters

The environment determines where your test requests are sent. You can have different environments for:

Local development (http://localhost:8000)

Staging (https://api-staging.example.com)

Production (https://api.example.com)

Switch between them easily without changing your test scenarios.

Run Your First Test

Now comes the exciting part—running your test and seeing if it works.

Run the test scenario

Make sure your Pet Store User API is running locally at http://localhost:8000

Select the environment in which you want the requests to run (Local Development)

Click the Run button at the top of the test scenario

Apidog will send the request to your local API and show you the results

What you'll see

After running, you'll see a test report showing:

Status: Passed or Failed

Response: The actual response from your API

Response time: How long the request took

Status code: The HTTP status code (should be 201 for successful registration)

If everything worked, you'll see a green checkmark and status code 201. The response should include the created user object with fields like id, email, firstName, lastName, and createdAt, but not the password (which is correctly excluded for security). Congratulations—you just ran your first automated test for your Pet Store User API!

Understanding the test report

The test report shows you exactly what happened:

Request details: What was sent to the API

Response details: What the API returned

Timing information: How long everything took

Click on "more" to inspect the actual request and response details:

This is valuable information. You can see if the API responded correctly, how fast it was, and what data it returned. All automatically, without manually checking anything.

See details Running Tests

Key Takeaways

Use Test Scenarios for organizing and running tests

Import efficiently from API specs or cases

Verify results using practical examples (e.g. user registration)

What's Next

You have a working test scenario, but it's pretty basic. Right now, it just sends a request and shows you the response. It doesn't verify that the response is correct, or check that the data was stored properly.

In the next chapter, we'll learn how to:

Pass data between multiple requests (like using a token from login in subsequent requests)

Add assertions to verify responses are correct

Build complete integration tests that test entire workflows

You'll see how to test the complete Pet Store User API lifecycle: register → login → update → delete. All automatically, all verified. We'll use the same Pet Store User API you built in the Developing APIs chapter, so you'll be testing a real, working API.

Continue with → Integration Testing and Data Passing

Getting Started: Your First Test Scenario

Before you start#

Create Your First Test Scenario#

Open the Tests module#

Create a new test scenario#

Why test scenarios matter#

Add Your First Test Step#

Add a test step#

Option 1: Import from endpoint spec (Recommended for beginners)#

Option 2: Import from endpoint case#

Option 3: Add custom request#

Understanding the difference#

Configure Your Test Request#

Choose your environment#

Why this matters#

Run Your First Test#

Run the test scenario#

What you'll see#

Understanding the test report#

Key Takeaways#

What's Next#