What is Assertion?

An assertion is a statement in a test that checks whether an actual result matches an expected result, if the condition holds, the test continues or passes; if not, the assertion fails and marks the test as failed. Assertions are what give a test its verdict.

Start a Free Mock Interview

Free to start · 7-day trial on paid plans

IN DEPTH

In depth.

A test without assertions does not really test anything, it just exercises code. The assertion is the verification step that turns activity into a meaningful pass/fail check: assert that the response status is 200, that the total equals $45, that the element is visible. Frameworks provide assertion libraries (JUnit/Hamcrest, Chai, Jest's expect, AssertJ, Cypress should) with expressive matchers.

A key distinction is hard versus soft assertions. A hard assertion stops the test immediately on failure, useful when subsequent steps make no sense if this one failed. A soft assertion records the failure but lets the test continue, then reports all failures at the end, useful when you want to check several independent things in one run (for example, validating many fields on a form) without stopping at the first problem.

Good assertions are specific and meaningful: they check the actual behavior that matters with clear failure messages, rather than being too loose (asserting something trivially true) or too brittle (asserting on incidental details that change often). Strong assertion design is a big part of writing tests that fail for the right reasons and are easy to diagnose.

WHY IT MATTERS

Why interviewers ask about this.

Assertions are fundamental to automation interviews. Explaining hard vs soft assertions and what makes a good assertion (specific, meaningful, clear failure message) shows you understand what actually makes a test verify something, not just run code.

EXAMPLE

Example scenario.

A form-validation test uses soft assertions to check ten fields in one run: it records that two fields show the wrong error message and continues, then reports both failures at the end, so the team fixes both at once instead of discovering them one slow test run at a time.

TIP

Interview tip.

Define an assertion as a check that the actual result matches the expected result, producing the test's pass/fail verdict. Contrast hard assertions (stop on first failure) with soft assertions (collect all failures, report at the end), and note that good assertions are specific with clear failure messages.

FAQ

Frequently asked questions.

What is the difference between a hard and a soft assertion?

A hard assertion stops the test immediately when it fails, appropriate when later steps depend on it. A soft assertion records the failure but lets the test continue, then reports all collected failures at the end, useful for checking several independent things (like many form fields) in one run without stopping at the first failure.

What makes a good assertion?

It checks the specific behavior that matters, with a clear, descriptive failure message, neither too loose (asserting something trivially true, so the test never really fails) nor too brittle (asserting on incidental details that change often). Good assertions make tests fail for the right reasons and are easy to diagnose.