Don’t use assertTrue to verify a text

Published by Elias on


It is common, especially in functional tests on any front-end (web, mobile), to include text validation in our tests to verify that the returned value is the expected one. These validations are user failures or even information about a successfully executed command.

However, it is common to see many professionals using the assertTrue command instead of assertEquals to validate the returned text.

This article has the intent to show the difference between the two main methods to verify any information in an automated test script. I have seen in my career on teams and even on tech assignments, people confused and not using the proper method for their context.

I will show you why this is bad practice!

Differences between assertTrue and assertEquals

Those commands can be found in Java testing libraries like JUnit or TestNG and we call these methods assertions.


The assertEquals assertion will compare the expected information you have to be equals to the actual information from your target (E.g: a text on a web page).

The assertEquals method has the following syntax:

assertEquals(actual, expected);

The first parameter actual is the actual result we think is correct. The second parameter expected is the expected result from your target.

Let’s imagine you have an automated test script and you must verify, after a click on a delete icon, if the message is “Record deleted”.

// imagine that this text came from the webpage
String actualResult = "Record has been deleted";

assertEquals(actualResult, "Record deleted");

Notice that the difference between them is the “has been” text inside the actual result, that one came from the webpage. When you have this problem during the test execution you can see an error like this one:

Expected :Record deleted
Actual   :Record has been deleted

On the first line, you can see the problem (exception) type: (ComparisonFailure).
On the second line, you can see the expected result, in other words, the text you expected after hitting the delete button.
On the third line, you can see the actual result, in other words, the text that the webpage returned.

The use of assertEquals makes much easier to know what the problem is and the difference between the expected and actual results.


The assertTrue assertion will compare the expected result against true or false verification. If your result is true you have success, otherwise, an error will be shown.

The correct way to use the assertTrue is:

boolean hasRestriction = true;


In the case of a false value for hasRestriction attribute an error will be shown:

	at org.junit.Assert.assertTrue(
	at org.junit.Assert.assertTrue(

Did you manage to easily identify the problem through the error message?
I didn’t!

We can infer where the problem was generated, but only in this case that we have only one validation. How about the scenario where we have several ones?

The wrong way I’ve seem…

I believe this is the wrong way because I do not have a result where I can, quickly, understand the problem, so I cannot take an action right away (fix the test, open a bug, etc…)

String name = "Elias Nogueira";
String city = "Amsterdam";
String jobPosition = "QA Engineer";
String experience = "20 years";

assertTrue(name.equals("Elias Nogueira"));
assertTrue(jobPosition.equals("Lead QA Engieer"));
assertTrue(experience.equals("20 years"));

Notice that we have only one difference in the assertion, comparing to the String provided: the jobPosition. If you use the assertTrue, like the example above, you will see the following error:

	at org.junit.Assert.assertTrue(
	at org.junit.Assert.assertTrue(

It’s not so informative, right? To track down this error and understand what is wrong, you must:

  • See which data was used on the webpage
  • Open the code on the specified line and see the expected result
  • See the difference between them

The recommended way…

We have the following example using assertEquals:

String name = "Elias Nogueira";
String city = "Amsterdam";
String jobPosition = "QA Engineer";
String experience = "20 years";

assertEquals(name, "Elias Nogueira");
assertEquals(city, "Amsterdam", city);
assertEquals(jobPosition, "Lead QA Engineer");
assertEquals(experience, "20 years");

This test will fail. Notice, in the error below, the difference between the two compared texts.

Expected :Lead QA Engineer
Actual   :QA Engineer

Now it’s easy to understand the real problem and take action without a great effort: I’m expecting the text “Lead QA Engineer” but the actual result, for example, the webpage, is “QA Engineer”.


On the code below you can have a small example comparing different ways to assert a text.


We have learned the difference between assertTrue and assertEquals, and how the use of assertEquals brings a clear vision about what the error is without open the code and try to search for the text differences.


I help professional software engineers (backend, frontend, qa) to develop their quality mindset and deliver bug-free software so they become top-level developers and get hired for the best positions in the market.


Dan · March 16, 2020 at 6:51 PM

Great post, the main goal when we’re trying to identify an error is get a clear log exception, so when we know how to use correctly assertTrue or assertEquals this contributes to build a code more efficiently.

Oriol · August 20, 2020 at 9:51 PM

I agree with this approach. The only exception, for me, is when the text is in a list and you don’t know the position of the text, and I add a description to understand what is wrong. Like this:

{ Assertions.assertEquals(path, result.path) },
{ Assertions.assertEquals(2, result.messages.size) },
result.messages.contains(“field1: must not be blank”),
“field1: must not be blank”
result.messages.contains(“field2: must not be blank”),
“field2: must not be blank”

Leave a Reply

Avatar placeholder

Your email address will not be published.