Learning Selenium – part 2

Basics of test automation with Selenium – Part 2junit

In my last post, I presented how to start writing test codes with selenium in java.
In this post, I’ll present how to write a code using a test framework, like Junit. The code will be updated in every post.

If you don’t remember my previous post, or didn’t saw it yet, click here.

As an experienced developer in test, you note some strange things in my post. Why I use the if/else to print the result? Every time I run my tests I have to read the console or a log file to know if the test passed?
Obviously no and this is against all we know and believe about automation, right? We can’t expect any human interaction in an automation task.

We have to use some test framework to do this for us, and provide a report with all results. We will use Junit for this.
Junit is a test framework, initially created for unit testing. But, today is used for automation tests, including regression, integration, etc.
I will talk about junit, but most of the examples and features has similarities in TestNG. I do not prefer one than other, is only the tool I learned and currently use.

First, you have to update your pom.xml to get the latest junit library:


The tag version with the bracket and the parenthesis brings you the 4.11 and up version of junit. The scope tag, with test, ensure that this library will be used only on a test phase, will not be compiled or used in runtime, for example. This is important when you write your test code in the same project than the application code.

Junit use annotations to drive the test flow, and is called fixtures. The five basic fixtures are:

@BeforeClass – the contents of this method will run first. It runs before all others.

@Before – this method contents will be processed before every test method.

@Test – the test method. Must contains all test logic and validation.

@After – Runs after every test method.

@AfterClass – Run at the end of all. Last step of flow.

the @Test method is the main process. You can have at least one, and how much you need. In it you will do the mains executions of the test and do the validation too. You have to split all pre and pos test to the @Before and @After methods. All major preparation (db connections, for example), have to be in @BeforeClass and @AfterClass.

Ok, lets rewrite our code, using these fixtures:

WebDriver driver;

public void setUp() {
driver = new FirefoxDriver();

public void shouldTypeInGoogleQuery() {
WebElement searchField = driver.findElement(By.id("gbqfq"));
WebElement searchButton = driver.findElement(By.name("btnG"));



assertTrue(driver.getPageSource().contains("Wikipedia, the free encyclopedia"));

public void tearDown() {

private void waitUntilTitleContains(String titleExpected)
WebDriverWait wait = new WebDriverWait(driver, 20);

The main changes from the older code:
line 1  – created a class attribute for the webDriver;
line 3  – put the browser definition and url in the preparation cycle (@Before) for the test. This will have a good use in the future…
line 9  – the logic is in the @test method. Note the name for the method: it has to mean something…
line 17 – put the “wait process” in a private method. I will reuse it on future…
line 19 – where are the if/else validation? Replaced by junit assertions…
line 22 – when my test finishes, I close the browser…

The most important part is the use of fixtures and the use of the assertions. Before, we do our validation on a console output, this time, we see nothing… On the console.
When using Junit, you’ll see the junit report output, showing you this:
junit_report_1This image shows a sucessful test execution. Note the name of the test method…

junit_report_2An example of what happens when something goes wrong, or when an error occurs. In this case, the page title is not what I expected, and after 20 seconds, the junit raises a timeout exception.

junit_report_3In this case, everything looks fine with the environment, but the feature didn’t do what I expected. I changed the string pattern to look on page – before was “Wikipedia, the free encyclopedia” and now I expected “You will never find me…”. I know that string won’t appear in page, just to force and assertion error…

I prefer use assertEquals instead assertTrue, when it’s possible. When you can compare two objects, use it. The result for success is the same from picture 1, but when the comparison fails, the results like this below:

junit_report_4I expect that the page title will be only ‘automation’, but it was ‘automation – Google Search’. Note how Junit result show the difference around brackets. This is important to know where the error is.

This output from junit can be viewed on the target/surefire-reports/TEST-..xml and some output on target/surefire-reports/..txt.
These files will be a great help when we integrate our test process on CI tools like Jenkins.

That’s it for this post.

See you in the next !


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s