TestNG Assertions Explained with Examples (Complete Guide for Selenium Automation Testing)

Learn all TestNG assertions with real Java examples, including hard vs soft assertions, Assert class methods, and best practices for Selenium automation testing.

I kept seeing Selenium tests pass when they shouldn’t and fail when nothing changed. Most of it came down to how we used TestNG assertions. This is a practical breakdown with examples, not theory.

Not a Medium member? Drop a comment and you will get the free access link

The day our tests lied

We had a build that went green. CI said everything was fine.

Production said otherwise.

A checkout flow was broken. Payments failing. UI looked okay at a glance, but something subtle was off. Our Selenium suite didn’t catch it. Not even once.

Later we realized… the assertion was technically correct. Just meaningless.

That stung more than a failing test.

Where things actually go wrong (not in code, in habits)

In most teams I’ve worked with, including the current one, coding doesn’t happen in long stretches anymore. It’s broken.

Standup → quick fix → JIRA update → PR review → unexpected bug → back to story.

Somewhere in between, you write tests. Fast.

Assertions become… rushed decisions.

Flow usually looks like this:

ambiguous requirement ↓ UI partially implemented ↓ test written with loose validation ↓ assertion checks something “close enough” ↓ test passes ↓ feature breaks later in a slightly different way

And then we say, “flaky tests”.

Sometimes they’re not flaky. They’re just weak.

Hard assertions are simple. Too simple sometimes.

TestNG gives you Assert. Straightforward. Fail fast.

import org.testng.Assert;

@Test
public void loginTest() {
    String actualTitle = driver.getTitle();
    Assert.assertEquals(actualTitle, "Dashboard");
}

Looks fine.

But here’s the thing — this test stops at the first failure. Always. Which sounds good… until you actually debug.

We had a page where:

• Title was wrong
• Username wasn’t displayed
• API response was delayed

Hard assertion caught only the first one. The rest stayed hidden.

Debug cycle got longer. Not shorter.

Soft assertions felt like a fix. They weren’t, at first.

Then we switched to SoftAssert.

import org.testng.asserts.SoftAssert;

@Test
public void dashboardTest() {
    SoftAssert softAssert = new SoftAssert();

    softAssert.assertEquals(driver.getTitle(), "Dashboard");
    softAssert.assertTrue(isUserNameVisible());
    softAssert.assertTrue(isBalanceDisplayed());
    softAssert.assertAll();
}

Now we saw everything that failed in one run.

Better visibility. Definitely.

But for a while, tests started passing even when they shouldn’t.

Because someone forgot assertAll().

One line. Missing.

Entire failures ignored.

That small realization

Assertions are not just validations. They define what “correct” means in your system.

We were asserting UI text.

But bugs were in API responses.

We were checking presence.

But not correctness.

That mismatch explains most “why didn’t the test catch this?” questions.

The Assert methods people use… and misuse

There are a few TestNG methods everyone knows:

• assertEquals
• assertTrue
• assertFalse
• assertNull
• assertNotNull

But usage matters more than the method.

Example from a real bug:

Assert.assertTrue(response.getStatusCode() == 200);

This passed.

But the payload was wrong.

We never asserted the data. Only the status.

Later we changed it to:

Assert.assertEquals(response.jsonPath().get("status"), "SUCCESS");

Bug caught immediately.

Not because TestNG changed. Because we asked a better question.

Small pattern we started following (helped more than expected)

We introduced a simple internal rule. Nothing fancy.

One assertion = one intent

Not:

Assert.assertTrue(title.contains("Dashboard"));

Instead:

Assert.assertEquals(title, "User Dashboard");

Stricter. Slightly annoying at times.

But test failures became… meaningful.

Slight detour — CI/CD made this more visible

When we plugged tests into CI pipelines, weak assertions became obvious.

Tests were passing too easily.

Velocity looked great on dashboards.

Delivery… not really.

There’s something odd here:

Velocity metrics went up. Bug reports also went up.

That combination shouldn’t exist. But it does.

A few things that still bother me

Soft assertions help. But they also delay failure visibility.

Hard assertions fail fast. But hide context.

There’s no clean answer.

Also, writing strong assertions takes time. And time is exactly what gets squeezed between sprint commitments.

And AI-generated tests? They tend to assert obvious things. Safe things. Not critical things.

Which is… expected.

AI writes the code. Someone still decides what deserves to be verified.

Best practices we ended up with (not perfect, just practical)

We didn’t document these formally. They just stuck.

• Use hard assertions for critical path checks
• Use soft assertions for UI validation clusters
• Always validate data, not just status or presence
• Never skip assertAll() (we added a wrapper to enforce it)
• Avoid “contains” unless absolutely required
• Tie assertions to business logic, not UI structure

Still feels incomplete. Probably is.

Final thought

Tests don’t fail because TestNG is limited.

They fail because we define “correct” too loosely.

And sometimes… because we were in a hurry.