5. Web testing project structure

Structure without cucumber

The following picture represents our basic structure what we use for web testing:

TestBase contains the initialization and termination of a Selenium Webdriver. It usually contains a before() and after() method where we start and close web browser. In addition to this we setting up desired capabilities if needed.

Test classes are holding all of our test cases against the particular web page. Following the design language, each test class must inherit the TestBase class. If the group of test cases written in one class requires extra preconfiguration and tear down operations additional before() and after() method should be written in that particular test classes.

PageObjects are traditional Selenium page objects. They are mapping each web page in a separate class. All of the locators and operations which is related to a particular web page should be implemented in the corresponding Page Object class.

PageUtils is a utility class which contains useful workarounds for special wait conditions and operations what can be done with Selenium. An instance of PageUtils class should be used just in PageObject classes.

 

Basic structure of cucumber

The following picture represents a basic cucumber project structure:

Here we a lot simpler approach: a single TestRunner class, Features files with scenarios and a java class which contains all step methods. The step methods can be independent or dependant. The steps which are using a common global object or calling each other, are dependant steps. Otherwise they are called as independent steps. If we have independent groups of step methods then we can split them up into multiple classes.

In web testing independent step methods are very rare. All usual step methods need to use the same browser and the same WebDriver, which means we have at least one common global object.

If we want to separate dependent test steps into multiple classes then we need a container object to hold the common objects. Now the structure of the files look like this:

One of the recommended ways to solve this issue is to use PicoContainer as common object. More details can be found here. Cucumber will use the object factory to create a new instance of this class and it will be passed to all related step classes. Step classes need to hold the reference of the PicoContainer instance in a final variable to avoid any future changes at it. This means that the common object is responsible just to share data between step classes.

To call a step method from another class we need to create a new instance of the particular step class which will obviously contains the same common object. In case when we want use the same particular step class more than once, it’s worth to consider to initialize a field with it. Obviously, creating a field can be used only in one way. If both classes use each other in the same manner, than it will create an endless dependency list and java will throw a compile error.

The combination of traditional web testing approach and cucumber looks like this:


The above described cucumber structure now replaces the test classes and the TestBase class. For the first look the combination of those two is way more complex than the web testing or the cucumber structure was.

The step classes are the core of the structure. They are using the common object to access to the webdriver and create page objects to access the designed abilities of each page. Following the guidelines of the solution, the driver and the PageUtils instance shouldn’t be used directly in the Step classes.

Similar Posts from the author: