How Do Assertions Work?

public void testScript()
int count = 5;
assertTrue("the count is not greater than 0", count > 0);
assertTrue(count > 0);
assertEquals("the count is not 5", count, 5);
assertEquals(count, 5);

One of the things that you will use very frequently in test automation is assertions: 

  1. assertTrue
  2. assertEquals
  3. assertFalse

They allow adding verifications to the unit tests. 

If an assertion passes, the unit test execution continues. 
If an assertion fails, the unit test execution stops and the remaining code lines are ignored. 

 If we use them so much, how about we try to understand how they work? 

So, how do assertions work? 

For this task, we will look at the junit framework code from the GitHub repository: 

The class is the one that implements all JUNIT assertions: 

We will look first at methods that implement assertTrue. 


There are 2 methods that implement assertTrue: 

1. assertTrue method that takes 2 parameters: 

  • condition to be evaluated 
  • message to be displayed in case the assertion fails 

The code is so simple: 

public static void assertTrue(String message, boolean condition)
if (!condition)

If the result of evaluating the condition is false, the method fails because of the fail(message) method. 

The fail(message) method has 2 versions as well: 

public static void fail(String message)
  if (message == null)
   throw new AssertionError();
  throw new AssertionError(message);

The first fail(message) method checks if the message parameter is null. 

If it is null, it throws an exception. 
If the message is not null, it throws the same exception with the message as a parameter. 

public static void fail()

The second fail() method calls the first fail() method with null as parameter. 

2. assertTrue method with 1 parameter (condition to be evaluated)

public static void assertTrue(boolean condition)
  assertTrue(null, condition);

This method calls the first assertTrue() method with null as message. 

And this is all code needed for implementing assertTrue. 

A few things need to be noticed: 

  • both assertTrue methods are static; using static is not a good programming practice but sometimes it is necessary
  • the methods are very simple and short; one method calls the other 


Similar with assertTrue, there are 2 methods that implement assertEquals (actually more than 2): 

1. method with 3 parameters 

  • expected - expected value of the variable to be evaluated 
  • actual - actual value of the variable to be evaluated 
  • message - message to be displayed if expected is not equal to actual 

 compares expected and actual using the equalsRegardingNull() method.
 the method ends if the equalsRegardingNull() result is true.
 otherwise, the remaining code is executed.

 the remaining code is executed if expected is different from actual.
 an exception will be thrown.
 if both expected and actual are strings, a ComparisonFailure exception is generated. 
 otherwise, the method calls failNotEquals() method which calls fail().

public static void assertEquals(String message, Object expected, Object actual)

 if (equalsRegardingNull(expected, actual))

 if (expected instanceof String && actual instanceof String)
   String cleanMessage = message == null ? "" : message;
   throw new ComparisonFailure(cleanMessage, (String) expected, (String) actual);
   failNotEquals(message, expected, actual);

  if expected and actual are both null, returns true (expected = actual).
  if expected is null but actual is not, returns false (expected <> actual). 
  if expected is not null, it returns the result of comparing expected with actual.

private static boolean equalsRegardingNull(Object expected, Object actual)
  if (expected == null)
    return actual == null;
  return isEquals(expected, actual);
   if expected is equal to actual, it returns true.
   if expected is not equals to actual, it returns false.

private static boolean isEquals(Object expected, Object actual)
   return expected.equals(actual);

private static void failNotEquals(String message, Object expected, Object actual)
   fail(format(message, expected, actual));

2. method with 2 parameters (expected and actual values of the variable to be evaluated) 

This method calls the assertEquals method with 3 parameters and makes the first parameter null. 

public static void assertEquals(Object expected, Object actual)
  assertEquals(null, expected, actual);

So, what can we learn from this code? 

  • One of the best sources of learning how something works is the source code
  • If we want to learn how to code better, the source code of popular frameworks provides many good lessons. In this case, the code uses many small methods which are very simple and clear instead of bigger methods.
  • Use custom exceptions for making failures visible

Back To Basics - How does WebDriver driver = new FirefoxDriver(); work?

Have you ever thought how this line works?

WebDriver driver = new FirefoxDriver();

More specifically, why are 2 types needed for creating the driver object?

And why is it possible to create a WebDriver variable but instantiate it with a FirefoxDriver object?

You can find the answer here.

Want Success In Your Testing Career? Follow Iceland's Soccer Strategy

This is not an article about soccer.

It just uses soccer as a pretext.

Because good ideas are everywhere.

The European Soccer Championship is taking place these days.

It is in the quarterfinals phase with just 8 teams left:

  1. Poland - Portugal
  2. Wales - Belgium
  3. Germany - Italy
  4. France - Iceland

Iceland, in quarterfinals?

One of them is a big surprise: Iceland.

To get to quarterfinals, Iceland had 2 draws and 2 wins:

Iceland - Portugal 1 - 1

Iceland - Hungary 1 - 1

Iceland - Austria   2 - 1

Iceland - England 2 - 1

Iceland's opponents have the following populations:

Portugal - 10.4 million

Hungary - 9.8 million

Austria   - 8.4 million

England - 53 million

Iceland is one of the smallest countries in Europe with just above 300.000 people.

Soccer is popular in Iceland and was never too good.

It is a great achievement for the Iceland soccer team to qualify to the European Soccer Championship. 

To reach the quarterfinals of the championship is just incredible.

How did Iceland do it?

Was it a fluke, an accident, a stroke of luck?

Iceland beat England because his players were more motivated, had better execution and more desire.

But there is something else that explains the Iceland's success.

With such a low population, Iceland has a limited pool of players.

It has to do well with the players it has.

And that's what they did.

Iceland invested heavily in soccer

So they invested in training and more training.

Iceland took TV money from UEFA (Union of European Association) and invested it all in infrastructure, coaching and player development.

They build heated indoor fields all over the country (Iceland has very low temperature throughout the year and lots of snow) and helped hundreds of coaches get UEFA licenses.

There are so many UEFA licenses soccer coaches in Iceland that they have one for every 825 people.

Compare this with 1 for every 11.000 people in England.

There was no fluke in Iceland making it to the quarterfinal of the European championship.

The big  investment in soccer paid out big time.

Iceland no longer has a small soccer team in Europe but an important one.

And your point is, Alex?

As a tester or IT professional, if you want to have success in your career, you need to invest first.

Not in a house or in stocks.

Invest in yourself

Invest time, energy and money in your training.

Invest in growing your knowledge, your skills, your communication.

Expand your skills.

If you are a manual tester, learn programming and test automation.

If you know test automation, learn performance testing.

If you know performance testing, learn API testing.

Your knowledge and skills will mature as a result of the investment.

And the success will come shortly.

Shortcuts and Tips for Test Automation Beginners

Euclid, the inventor of geometry, was asked once by the ruler of Greece if there is a shorter road for learning geometry. 

There is no royal road to geometry, Euclid replied. 

There are no shortcuts to test automation with 

Tips are easier to give. 

So, before starting test automation, 
  • learn the programming language well
  • learn how to write clean code with your programming language