A closer look at Serenity BDD (Thucydides)

Hi everyone. Today I want to do a first step in writing of new tutorial series about automation testing of web applications. If to be more concrete I’m going to make an overview of Serenity BDD (Thucydides). I will consider ways of its usage and aspects of building testing framework with it. All stuff which I will talk about is related to testing of web applications. It’s not regular Page Object Patter, so let’s start!

Classical test automation approach

I have worked a lot in automation testing of web-applications. My main programming language is Java, hence it’s not weird that I prefer to work with frameworks developed with WebDriver + TestNG or JUnit. This is obvious choice since WebDriver established itself as reliable, free and open source solution. And of course each intelligent testing framework should be based on Page Object pattern.

Approximately in 2011 John Ferguson Smart has released the first version of Serenity BDD Thucydides – WebDriver based library aimed to help develop BDD acceptance tests. If to be true, in that time I was more interested in a web-development than in the test automation, but due to my position I had to worked with the test automation in e-commerce projects. This circumstance isn’t good or bad, it just means that I have acquired my own style of the test automation.

A main influence on my view of the test automation made a blog articles about handling of AJAX elements and a legacy testing framework which was developed by company’s java architect. In that moment I wasn’t aware about BDD automation style, but I recognised later that I used BDD features in my functional tests.

I still think that I develop testing frameworks in a classic manner. What does it mean? Well it’s pretty simple, my frameworks include following parts:

• Basic page class
• Basic test class
• Page classes
• Test classes

So as you see this structure has two abstract branches, the first one represents pages, the second one represents tests. Of course any testing framework with such architecture can be extended by some helpers, factories etc. This fact makes classical approach very flexible.
One additional smart decision is implementation of chaining for methods in page objects. Thanks to this tests become more readable and elegant:

basePage.clickLoginLink()
    .fillLoginForm("User", "password")
    .clickLoginButton()
    .checkTextPresent("Hello, User");

Summarizing information above, now I can start familiarity with Serenity BDD. I will do it by comparing the classical approach with that one which Serenity suggests to us. Someone can say that I don’t use Serenity BDD 100% correctly, but my main goal is to show how I use it in my understanding of correctness.

Nature of Serenity BDD

My first impression regarding Serenity BDD – everything you need for test automation is already done for you. Looks like John Ferguson Smart is really smart, if he laid down functionality which allows you to start test automation very fast with minimum of efforts. So how did John achieved this? I’ll try to answer this question till the end of the article.

First of all I want to notice that the creator of the Serenity, definitely fan of Agile methodology, because BDD approach suits well for such methodologies where a developer team get tasks in a form of user stories and need to develop them until acceptance tests will be successfully passed. This circumstance can easily explain components of Serenity BDD:

• Requirements
• Page objects
• Steps
• Tests

Someone can notice that I didn’t mention Reports in the list above. That’s not a mistake, because Reports in Thucydides are the result of Tests run. But let’s talk about Reports later when the time will come for this component.

Requirements are primary. Just after we get requirements it’s time to think about tests which will check correctness of functionality implementation. All available actions within an entire application are performed with certain page elements (e.g. click ob the Login link etc). The previous sentence was about Page objects, which serves as places where we declare web elements and methods which make some manipulations with them.

The next level of abstraction allows us to unite some methods from Page objects together in Steps methods. But why we need to combine methods from Page objects into Steps? It’s waste of time someone can say. But experienced software engineer will argue, because Steps help us to save a granularity of mini steps on a Page objects level and to achieve a logical completeness of steps on a Steps level.

Finally the methods from the Steps level entities can be used for an automation tests development. And as a result of the Tests runs you will get detail Reports.
The image below explains architecture of Serenity more concise and strict:

As a bonus to the elegant and logically correct architecture of Serenity BDD you get a very useful and convenient way to create a testing framework for a particular web-application. I talk about annotations. They are powerful enough to organise a code of entire project with a really high quality and readable form.

Summary

Everything I have written above sounds very optimistic and looks like advertisement. But this is not a fantasy, it’s just an example of how you should act if you think that you know how to do something better. John Ferguson Smart has developed Serenity BDD adhering his own vision of a good test automation. I think that I outlined here enough information for a high level comparison of these two approaches – classic and Serenity BDD.

In nearest two articles I will demonstrate how you can apply Serenity BDD for automated testing of a web application. I’ll try to be not so verbose as in this post, also I’ll provide concrete code examples.