Over a million developers have joined DZone.

Highly Maintainable and Flexible UI Test Automation - Part 2

DZone 's Guide to

Highly Maintainable and Flexible UI Test Automation - Part 2

Continue learning best practices and examples of automation in QA, including dos and don'ts for various UI testing procedures.

· DevOps Zone ·
Free Resource

This will be a story about the history of QA process in the division where I worked for over six years, related mainly to automation. I think that when I share it with you, you will not make the same mistakes and reuse our good practices from the beginning. You can find the first part here.

Mixing Test Levels Harness

You need the web service and library that wraps the web calls. To debug it, you need to have the full source code on your machine, deployed, and you need to attach to the process. If you want to add something new, test it- you need to write it first to the service. Then add a method to the contract interface. Add the wrapper method to another project and publish a NuGet. If you need to add lots of new code, the process becomes hell.

Usage Factories Test Web Service

Another problem that we had relates to the processes when you use logic for integration tests in your service. These methods sometimes change, or some developer might introduce regression. Then your tests start to fail, too.

Dos and Don’ts

  • Never couple tests harness from two different levels. Especially when different people are responsible for these levels.

Test Data Equipment- T4 Templates

A couple of years later. I decided that I did not want to waste time to do that exercise all of the time. Therefore, I made a few spike projects to test different data web services. For those of you who do not know what e data web service is- this is a service that allows you to make CRUD operations against a DB from a web service. However, there were few limitations back then, and this was not an option. I do not even remember anymore what the exact reason why we did not choose that. Anyhow, I just had finished a book related to T4 templates for code generation. Therefore, I decided to utilize their power to the maximum extent. I created four different templates for generating a wrapper and service method automatically for every table and property of our DB. It contained C# parser that parsed the DB model and every time on build created all of the files and classes.

T4 template Test Web Service

Dos and Don’ts

  • Do not couple production code with tests code. Our service depended on the production DB model. I think it is best if the test solutions have their DB layer.

Multiple Sites, One Project

Our team increased in size multiple times, and now we were 10 QAs. We had multiple new sites. Our tests were rewritten to use only code and no UI tools. They used the Testing Framework because we dog food all the time and the people from the testing division provided excellent support if needed. Back then, we had a single project for all different tests.

Dos and Don’ts

  • Create a separate project for each application. This way if someone breaks the build, not all tests are affected.

Fluent Interface

This is an example of what is the fluent interface. Every part of the chain returns an object for the next part. OpenTelerik returns the TelerikFacade. The method LoadFacades of the TelerikFacades returns an object of type ShoppingCartFacade and so on.

Fluent Interface Tests

Dos and Don’ts

  • It is better to use Inversion of Control container instead of a fluent interface. The fluent interface can be hard to get from new people. I was confused at the beginning.

We created this common/Core projects per site where the different facades and pages are placed so that they can be reused among different applications tests’ projects.

Common Projects

Dos and Don’ts

  • Do create separate projects for the core of the system tests’ framework.
  • Do choose the right names for the projects. Do not include names such as names of companies, teams, and divisions.
  • Do not develop your framework in a way where only a few people can change it and maintain it. What happens, when this person move to another division or leave the company? Besides, if changes are required, and they do not have time right now, they become bottlenecks for the whole process.
  • Dependencies

    Another problem that arose from the usage of NuGets was that our projects especially the core ones depended a lot on lots of external code. Therefore, when you use this NuGet, it brought tens of others DLLs. However, the biggest problem was that if you want to update one of this dependency you need to update all of the projects.

    Dos and Don’ts

    • Code against abstractions and use Inversion of Control container in the tests’ project to resolve them.

    Direct DB Access Era

    Instead of using our web service, we decided to retire it. Instead, we decided to have a dedicated DB project in our test solution. Besides, we built our complex arrange projects instead of using the production code ones. This way our tests were not dependent anymore on production code.

    Dos and Don’ts

    • Direct usage of DB in tests tend to make the tests much faster.
    • Do not write long end-to-end tests with hundreds of tests and asserts. Instead, try to write more isolated tests and much less long end-to-end large system integration tests.

    Direct DB Access

    Isolated UI Tests

    We had some tests that arrange the third step of the shopping cart process in the DB and asserted only the UI bindings. We had a separate test that made a few actions and asserted the state in the DB instead of the UI.

    Dos and Don’ts

    • Build separate tests for verifying the UI bindings and the business logic.
    • Speed up the tests reusing the browser.

    Project Structure

    A thing that I am most proud that we managed to do is to create a new QA TFS project. Where all test harness and tests are placed. The system tests framework was treated as a product. It had a dedicated solution and tests. All websites had their folder that used the system tests framework as a branch. This way every team could debug and make corrections to the framework. When they were ready, they could merge their branch to the main one. Once the code was merged if some of the tests fail, they needed to make the corrections when they have time. However, they could not break my tests since they used a separate branch.

    Projects Structure

    Dos and Don’ts

    • Build modular system tests framework that depends on abstractions. This way the different teams can use only the modules that they need. Instead of referencing all of the projects and depend on lots of external code they might not need.


    This was a short version of the history of the QA process in the division where I worked for six years. Many things happened. I believe that when I shared it with you, you will not make the same mistakes and reuse our good practices from the beginning. Good luck!

    devops ,ui testing ,test automation ,software testing

    Published at DZone with permission of

    Opinions expressed by DZone contributors are their own.

    {{ parent.title || parent.header.title}}

    {{ parent.tldr }}

    {{ parent.urlSource.name }}