Your UI can work perfectly while your API is broken

API testing is the most underrated layer in many test strategies. Faster, more stable, and closer to the business logic than what shows on screen.

You click through the application. Everything works. The buttons respond, the pages load, the form submits. You'd swear everything's fine.

And yet under the hood there's an API returning the wrong data, sending a 200 status on an error, or omitting a field the mobile app actually needs. The UI hides it. Until another client stops hiding it.

Why API testing is the underrated layer

Many test strategies stop at the interface. Understandable: that's what you see, and what the user sees. But the API is the backbone. That's where the business logic lives, where the data flows through, where multiple clients connect.

An API test runs in milliseconds, while a UI test needs seconds. It doesn't break because an element's locator changed. And it tests the business rule itself, not its display.

Postman or Bruno versus RestAssured

The choice between tools is less of a religious debate than people make it out to be. They're good at different things.

Postman / Bruno

Strong for exploration. You want to quickly see what an endpoint returns, tweak a header, try out a payload. Visual, low barrier to entry, no code needed. Ideal for getting to know an API, and for quickly sharing something with the team.

RestAssured

Code-first, in Java, and therefore fully at home in your CI/CD pipeline. Your tests live alongside your application code, go through code review, and run automatically on every build. Less suited for a quick try-out, much better suited for structural testing.

In practice most teams use both. That's not inconsistency, that's the right tool for the right job.

What you should always test

Status codes

200 on success, 201 on creation, 400 on a bad request, 404 on not found, 500 on a server error. Sounds obvious. It isn't. An API that returns 200 with an error message in the body is surprisingly common, and surprisingly problematic.

Response structure and data types

This is the contract. Which fields come back, of what type, which are required. Change that unnoticed, and you break your consumers. A contract test catches that before it reaches production.

Error handling and edge cases

What happens with an empty payload? A field that's too long? An ID that doesn't exist? A negative amount? Testing the happy path is the easy part. The edge cases are where it goes wrong.

Authentication and authorisation

Can a user get in without a token? Can user A request user B's data? This isn't just a testing question, it's a security question. And it gets skipped too often.

A concrete example with RestAssured

Here's what a test looks like that covers three of the four categories at once: status code, response structure, and authorisation.

// fetches a user and checks status, structure, and authorisation
@Test
void userWithoutTokenIsDenied() {
    given()
        .header("Authorization", "")
    .when()
        .get("/api/users/123")
    .then()
        .statusCode(401);
}

@Test
void userWithTokenGetsCorrectResponse() {
    given()
        .header("Authorization", "Bearer " + validToken)
    .when()
        .get("/api/users/123")
    .then()
        .statusCode(200)
        .body("id", equalTo(123))
        .body("email", notNullValue())
        .body("password", not(hasKey("password")));
}

Two tests, two assumptions verified: no token means no access, and a valid token returns exactly the fields the contract promises — no password field accidentally leaking into the response.

Where to start

If you have no API tests today: start with your most critical endpoint. The one where money flows through, or personal data, or the one the whole application leans on. Test the four categories above. Put it in your pipeline.

You'll be surprised how much you find in that one endpoint.

// Also as a carousel

This article first appeared as a carousel on LinkedIn.

View on LinkedIn