Testing CRUD Operations with Java, HttpClient, Gson, and JUnit

Welcome to another step in our journey to mastering automated API testing with Java. So far, you've learned how to organize tests using JUnit's setup methods. Today, we will focus on automating tests for CRUD operations — Create, Read, Update, and Delete — which are integral actions for managing data in any application that uses RESTful APIs. Automated testing of these operations is essential to ensure that APIs function correctly and modify resources as expected. Thorough testing of CRUD operations will help you catch issues early and ensure API reliability.

In automated testing, setup and teardown are fundamental concepts that help ensure each test has a clean start and finish. Setup is about preparing what you need before a test runs, like creating test data or setting up configurations. Teardown involves cleaning up afterward, removing any leftovers from the test, such as deleting test data, so future tests aren't affected. This process makes sure tests don't interfere with each other.

We'll use JUnit's @BeforeEach and @AfterEach annotations to make setup and teardown automatic. Imagine testing a todo API with CRUD operations:

• Setup Phase: Runs before every test to create a fresh todo item, providing each test with the necessary starting data.
• Teardown Phase: Runs after every test to delete the todo item, ensuring no leftover data impacts subsequent tests.

JUnit handles these phases automatically, before and after every test, keeping your tests independent and the environment clean.

To effectively manage setup and teardown for CRUD operations, we utilize JUnit's @BeforeEach and @AfterEach annotations. These annotations automate the process, ensuring each test starts with the right conditions and ends without leaving any trace. This means every test begins and ends with a clean state, which is crucial to avoid any interference between tests.

Here's an example of how the setup and teardown are structured in Java:

import com.google.gson.Gson;
import org.junit.jupiter.api.*;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;

class TestCRUDOperations {

    private static final String BASE_URL = "http://localhost:8000";
    private HttpClient client;
    private Gson gson;
    private String todoId;
    private Todo todoData;

    @BeforeEach
    void setup() throws Exception {
        client = HttpClient.newHttpClient();
        gson = new Gson();
        todoData = new Todo("Setup Todo", "For testing CRUD operations", false);

        HttpRequest request = HttpRequest.newBuilder()
                .uri(new URI(BASE_URL + "/todos"))
                .header("Content-Type", "application/json")
                .POST(HttpRequest.BodyPublishers.ofString(gson.toJson(todoData)))
                .build();

        HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
        if (response.statusCode() != 201) {
            throw new Exception("Failed to create a todo for setup");
        }
        todoId = gson.fromJson(response.body(), Todo.class).getId();
    }

    @AfterEach
    void teardown() throws Exception {
        if (todoId != null) {
            HttpRequest request = HttpRequest.newBuilder()
                    .uri(new URI(BASE_URL + "/todos/" + todoId))
                    .DELETE()
                    .build();
            client.send(request, HttpResponse.BodyHandlers.ofString());
        }
    }
}

Within this setup, the actions occur before each test to create a todo item, ensuring the test environment has the necessary data. The teardown actions delete the created todo, maintaining a clean slate for subsequent tests. This ensures consistent, independent test runs free from interference caused by leftover data. Bare in mind that, even though we could use an assertion to test the output of the setup method, these methods aren't considered tests. The focus is on setting things up for the tests, so we don't 'assert' the outputs, as they are expected to be correct. If they are not, an exception can be thrown and we need to fix the logic.