Organizing Tests with Classes and Fixtures in C++

Welcome back as we continue our journey into the world of API testing with C++. In our first lesson, we explored the fundamentals of using Google Test to automate simple API tests. Today, we're building upon that foundation to introduce a more structured approach to organizing and optimizing your tests. We'll focus on using classes and fixtures within Google Test, tools that will help you write cleaner and more efficient code. Understanding these concepts will empower you to manage your tests more effectively as they grow in complexity and scale.

Fixtures are a powerful feature of Google Test that allows you to extract the setup code you often have to repeat across different tests. By defining fixtures, you can reuse pre-specified setups or data configurations in multiple test functions, making your code more maintainable and less error-prone.

To create a fixture in Google Test, you define a test class that inherits from ::testing::Test. You can then override the SetUp() and TearDown() methods to handle any setup and cleanup tasks. In this lesson, we will focus on the SetUp() method to demonstrate how to prepare the necessary environment or data before each test runs. Here's how you can create and use a fixture:

#include <gtest/gtest.h>
#include <string>

class TodoTest : public ::testing::Test {
protected:
    std::string title;
    std::string description;

    void SetUp() override {
        // This function sets up a to-do item
        title = "Test API with Google Test";
        description = "Write tests using Google Test and httplib";
    }
};

In this example, TodoTest is a fixture class that sets up a to-do item. The SetUp() method is used to initialize the necessary data before each test runs. This mechanism is part of the Arrange step in the Arrange-Act-Assert pattern, where you prepare the necessary data or state before executing the main action of the test. By using fixtures in this way, you ensure your test preparations are clear, reusable, and separated from the test logic itself, making your tests more concise and enhancing their readability and reusability.

Let's see how combining fixtures and classes comes together in a test scenario where we create a new todo item. Using the TodoTest fixture class, you can simplify and streamline the Arrange-Act-Assert pattern.

#include <gtest/gtest.h>
#include "httplib.h"
#include <nlohmann/json.hpp>
#include <string>
#include <iostream>

using json = nlohmann::json;

// Google Test fixture for API testing
class TodoTest : public ::testing::Test {
protected:
    std::string title;
    std::string description;

    void SetUp() override {
        title = "Test API with Google Test";
        description = "Write tests using Google Test and httplib";
    }
};

// Test case: Create a new TODO item via API
TEST_F(TodoTest, CreateTodoWithFixture) {
    httplib::Client cli("http://localhost:8000");

    // Prepare JSON payload
    json payload = {
        {"title", title},
        {"description", description},
        {"done", false}
    };

    std::string json_payload = payload.dump();

    // Send POST request
    auto res = cli.Post("/todos", json_payload, "application/json");

    // Check if the request was successful
    ASSERT_TRUE(res != nullptr);
    EXPECT_EQ(res->status, 201);

    // Log response
    std::cout << "Response Code: " << res->status << std::endl;
    std::cout << "Server Response: " << res->body << std::endl;
}

In this example, the CreateTodoWithFixture test function leverages the TodoTest fixture to provide the necessary data for the POST request. The fixture initializes the title and description fields, which are then used to construct a JSON payload representing a new todo item. This setup allows the test to focus on the core action—sending the request and verifying the response—without being cluttered by repetitive setup code.

The test proceeds by creating an httplib::Client instance to interact with the API. The JSON payload is created using the nlohmann::json library, which is then serialized into a string format suitable for transmission.

The cli.Post function is used to send the POST request with the JSON data. The response is checked to ensure the request was successful, expecting a 201 Created status. By using fixtures, the test remains focused on verifying the API's behavior, while the setup details are efficiently managed by the fixture class.

When the test is executed, you should see output similar to the following, indicating that the test passed and the server responded as expected:

[ RUN      ] TodoTest.CreateTodoWithFixture
Response Code: 201
Server Response: {
    "id":1,
    "title":"Test API with Google Test",
    "description":"Write tests using Google Test and httplib",
    "done":false
    }
[       OK ] TodoTest.CreateTodoWithFixture (XX ms)
[----------] 1 test from TodoTest (XX ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (XX ms total)
[  PASSED  ] 1 test.

In today's lesson, you gained insight into enhancing your test structure using Google Test's classes and fixtures. Fixtures help you streamline test setups, making your tests more efficient and easier to maintain. By organizing tests in classes, you can manage them more effectively, particularly as your test suite expands.

Now it's time to apply what you've learned. The practice exercises that follow are designed to help you reinforce these concepts through hands-on practice. Dive into these exercises to deepen your understanding and gain confidence in writing structured and efficient API tests using Google Test and httplib. Keep experimenting, and remember that the more you practice, the more proficient you'll become in automating API tests.