DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Securing Your Software Supply Chain with JFrog and Azure
Register Today

Trending

  • Revolutionizing System Testing With AI and ML
  • Software Development: Best Practices and Methods
  • Getting Started With Istio in AWS EKS for Multicluster Setup
  • Introduction to API Gateway in Microservices Architecture

Trending

  • Revolutionizing System Testing With AI and ML
  • Software Development: Best Practices and Methods
  • Getting Started With Istio in AWS EKS for Multicluster Setup
  • Introduction to API Gateway in Microservices Architecture

Don't Use assertTrue to Verify Text in Your Test

Elias Nogueira user avatar by
Elias Nogueira
CORE ·
Sep. 07, 20 · Tutorial
Like (4)
Save
Tweet
Share
6.16K Views

Join the DZone community and get the full member experience.

Join For Free

Introduction

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.

assertEquals

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:

Java
xxxxxxxxxx
1
 
1
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”.

Java
xxxxxxxxxx
1
 
1
// imagine that this text came from the webpage
2
String actualResult = "Record has been deleted";
3
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:

Java
xxxxxxxxxx
1
 
1
org.junit.ComparisonFailure: 
2
Expected :Record deleted
3
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 it much easier to know what the problem is and the difference between the expected and actual results.

assertTrue

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:

Java
xxxxxxxxxx
1
 
1
boolean hasRestriction = true;
2
assertTrue(hasRestriction);


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

Java
xxxxxxxxxx
1
 
1
java.lang.AssertionError
2
    at org.junit.Assert.fail(Assert.java:86)
3
    at org.junit.Assert.assertTrue(Assert.java:41)
4
    at org.junit.Assert.assertTrue(Assert.java:52)


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 Seen…

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…).

Java
xxxxxxxxxx
1
 
1
String name = "Elias Nogueira";
2
String city = "Amsterdam";
3
String jobPosition = "QA Engineer";
4
String experience = "20 years";
5

          
6
assertTrue(name.equals("Elias Nogueira"));
7
assertTrue(city.equals("Amsterdam"));
8
assertTrue(jobPosition.equals("Lead QA Engieer"));
9
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:

Java
xxxxxxxxxx
1
 
1
java.lang.AssertionError
2
    at org.junit.Assert.fail(Assert.java:86)
3
    at org.junit.Assert.assertTrue(Assert.java:41)
4
    at org.junit.Assert.assertTrue(Assert.java:52)


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:

Java
xxxxxxxxxx
1
 
1
String name = "Elias Nogueira";
2
String city = "Amsterdam";
3
String jobPosition = "QA Engineer";
4
String experience = "20 years";
5

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


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

Plain Text
xxxxxxxxxx
1
 
1
org.junit.ComparisonFailure: 
2
Expected :Lead QA Engineer
3
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”.

Example

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

Java
x
29
 
1
import static org.testng.Assert.assertEquals;
2
import static org.testng.Assert.assertTrue;
3

          
4
import org.apache.commons.lang3.StringUtils;
5
import org.testng.annotations.Test;
6

          
7
public class AssertionTest {
8

          
9
    public static final String ACTUAL = "text wrong here";
10
    public static final String EXPECTED = "text right here";
11

          
12
    // not recommended
13
    @Test
14
    public void usingAssertTrue() {
15
        assertTrue(ACTUAL.equals(EXPECTED));
16
    }
17
 
18
    // best one
19
    @Test
20
    public void usingAssertEqual() {
21
        assertEquals(ACTUAL, EXPECTED);
22
    }
23

          
24
    // not recommended
25
    @Test
26
    public void usingAssertTrueAndStringUtils() {
27
        assertTrue(StringUtils.equals(ACTUAL, EXPECTED));
28
    }
29
}


Conclusion

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.

Testing

Published at DZone with permission of Elias Nogueira. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Revolutionizing System Testing With AI and ML
  • Software Development: Best Practices and Methods
  • Getting Started With Istio in AWS EKS for Multicluster Setup
  • Introduction to API Gateway in Microservices Architecture

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: