AUTOMATION 24 - GUI 11, unlocking true automated checking with JUnit

Techncial level: *****

To date we’ve had a couple of experiments with Selenium WebDriver using Java – these centered on,

• learning how to use commands
• the basics of the WebDriver / WebElement objects
• how we can manipulate and read page content.

What we haven’t really done so far is create an automated check.  Oh, we’ve used "if" statements to do comparisons and put content to screen to see what happens, but much like with our initial testing of dice classes under unit testing, it requires someone to look through screen output and go “yeah … that’s okay”.

In the words of Phillip J. Fry, “that dog won’t hunt, Monsignor”.  It's automatic execution, with manual checking.  We can do better!

To unlock the power of Selenium WebDriver, you need something which will assert and report if something is true – and in Java that’s the JUnit framework.

The Junit framework allows you to define multiple @Test test methods which are run as part of your build process.  An important part of these methods is the assert command such as AssertTrue and AssertFalse.

AssertTrue ( error_txt, Boolean_comparison);

AssertFalse ( error_txt, Boolean_comparison);

These commands are similar – they have two arguments

• error_txt – If the assertion fails, this is the unique identifier that will be written to the Junit log to say what was being asserted, so the person running these tests can work out where the failure occurred and why
• Boolean_comparison – this is the thing you’re comparing (that must reduce to a Boolean true/false result). Pretty much to create most of my assertions, I’ve moved my check from an “if” command to this value under the assertion.

If the assert command fails, then the JUnit test stops immediately, and an error raised in the JUnit log.

Sometimes though you want to check something, but you don’t want it to absolutely fall over if it’s not true – for that you can use a verify tactic.

try {
assertTrue("Verify the page contains that red aardvark",
(element.getText().contains("red aardvark"))  );
}
catch (Error e) {
System.out.println("ERROR");
System.out.println(e.toString());
}

This uses the same AssertTrue command, but wraps it in an exception handler (a try … catch command in Java).  This allow you to take action if it fails – if the try condition fails, it executes the catch functionality.  I’ve just got the catch here printing to the screen that something went wrong here, but you could have it writing to a log file if you want, and have the Java skills.

In Script 3 - which you can see here or here, I’ve collected together my tests from scripts 1 and 2 into a single set of Junit tests, and adapted them to work best in the Junit framework,

It’s tempting to have assertions all over the place – but it pays to be sparing.  You should only want to check a core set of things per Junit test, and they ideally should relate to the title of your test.  The test “checkForRedAndBlue” is pretty obvious (it's our test for blue and red aardvarks) – but if you included assertions for the comments box it could get confusing – when “checkForRedAndBlue” fails, it should be for a reason linked the title.  Such checks make much more sense under “createCommentAndReview”.

One difference to that is that I’m using the page title check as confirmation I’m on the right page before continuing.  It’s pretty important that I’m on the right page, otherwise everything I check afterwards is pretty pointless.  I could have chosen a half dozen attributes and check them ALL – for instance,
•    Page title is "I'm hoping that this blog will have the most comments"
•    URL is http://testsheepnz.blogspot.co.nz/2016/07/im-hoping-that-this-blog-will-have-most.html
•    Page contents include “I'm hoping that this blog will have the most comments”

But it makes more sense to keep it simple (one of our iron rules) and choose something simple to test – so I’ve done with page title.

You will notice if you run this code that test “thisTestWillFail” does exactly what you’d expect … and fails due to a bad assertion.  I wanted you to be able to see that – you need the information in your assertion to make sense when this does happen.

Perhaps you’d like to have a go at turning it from an assertion into a validation using exception handling as we’ve seen before?

Extension material

Attempt to create your own JUnit tests for my blog page, and include your own assertions.


Intermission

We're about 2/3 of the way through the curriculum material I've planned out.  I'm going to take an intermission at this point and start a new series to look at some Java basics.

As we've gone through this series, the technical difficulty level has been increasing, and I want to provide an opportunity for those who want to get deep into the automation code to get up to speed before we continue into our most important area yet - the one we've all invested all this time to get to ... useful, maintainable checking automation.