Abstracting the Test Layer using TestNG

The library architecture is popular among test automation framework designers. To follow this pattern, engineers decompose and abstract the automation logic at various conceptual levels, such as at the page, the component or at the element level. But usually, the test layer is left out of these decomposition efforts.

Leaving abstraction out of the test layer can in time lead to duplication of the logic as well as having to spend more time than what is required to script new scenarios. This post will discuss how the test layer can be abstracted and decomposed using TestNG.

High-level Steps

1. Start with designing and implementing test cases so that they are atomic
2. Encapsulate the test layer by scripting the test steps and adding assertions required to validate the component. Then put a mechanism in place to read the test data from an object that can be passed from one test class to another as required.
3. Finally, use the Factory feature in TestNG to compose the larger scripts using the test classes.

Let’s take a crude example of validating a web page with a dropdown[1]. For this example, I have identified the two test cases seen below,

1. Validate that the dropdown page loads the dropdown and that the values are as expected.
2. Validate that the dropdown allows the user to select the option he wants to select.

The test layers for the two test cases were scripted as seen below and were joined together using the factory annotation in the DropDrownTest class. Notice how the same test data object is passed between the two test cases.

Test Class 1

Test Class 2

Factory Class

[1] - https://the-internet.herokuapp.com/dropdown

[repo] - https://github.com/handakumbura/SeleniumAutomationEmployerProfile/tree/feature/atomic_test_cases

Moving from Selenium to Protractor for Web Automation

99x Technology invests heavily in Quality Assurance, and this one of the reasons why the company has been able to carve out a name as a trusted product engineering company. The brunt of the QA work at 99x is achieved using automation, specifically protractor. 

As someone who is familiar with Selenium,TestNG and Java, I found myself a little intimidated at the prospect of learning a new stack including a new language(javascript) but to my delight I found the experience to be relatively pain-free and intuitive. In hindsight, I can clearly see the reasons as to why making the shift from Selenium to protractor makes sense.The main reasons as I see it are,

The fact that Angular and JS is taking over the web

As a technology invented and backed by Google, it was just a matter of time before AngularJS piggy backed into becoming the dominant web application technology around. Naturally, as Protractor is custom built to test angular apps, it makes sense to use it to test angular apps.  

Not having to meddle around with the web drivers 

Downloading the latest greatest web driver for each browser being tested and then setting up the driver in code and all the other steps that follow are pains associated with Selenium. As protractor is built as an API encapsulating selenium, it takes care of most of these pains. All you have to do is run the command to update and start the drivers and the API takes care of the rest. 

Not having to meddle around browser weights(sort of!)

Unlike Selenium Protractor provides is hard-wired for implicit weights for elements, it also supports explicit waits in the way of actions and browser sleep operations.

The backing of a Healthy community

Personally, i found the protractor community to be more active compared to that of Selenium’s. Maybe this is because its relatively. As protractor is built as an Node.JS package, it benefits from the NPM community. You can easily find extensions like reporters and data providers.    

....

Moving on, when making the switch(given you’re moving from java to javascript,  I did), give special attention the fact that JS is an asynchronous language, meaning, the language may process two program statements inside a code block parallelly as opposed to processing them sequentially as we expect in Java. The protractor API hides the complexities of working with the asynchronous nature of JS whenever you’re performing an action on the browser but whenever you’re receiving data from the browser to the test code, you need to explicitly handle the logic required to handle the parallelism, this is done through a mechanism named promises.

I’ve put together a project[1] that automates a set of test-cases for a banking app put up by way2automation tutorials site. The project uses most features available in protractor as well as some of the main functionality of jasmine and some of its extensions such as the html/screenshot reporter. The project embeds protractor as node module, therefore it can be executed as follows(not the project is expected to be run on windows).

npm run webdriver-update

npm run webdriver-start

npm run start

In-container unit tests (Docker TestNG integration)

With the advent of containerization of applications and the proliferation of micro-services, there arise a need to test containers similar to the way jar’s(java libraries) are tested using unit testing mechanisms. The example below demonstrates one such method that unitizes an environmental variable to trigger a TestNG test suite from outside a container. 

1.  Put in the test trigger code in your applications entry point as shown below,




2. Create a container consisting your application jar file(s), make sure all dependencies are available inside the container. In the example project the testng.xml file and a jar consisting of the application and its dependencies are copied into the container.

3.  Run the container passing in the environmental variable as show below,




Find the example code base here[1]. Note that the container is made problematically using the docker main plugin.