Framework – Understanding The Basics

This series of articles will cover the basics of what we can define a framework as being, and go on to designing our own basic framework step by step. By the end of it, you’ll have a fully functioning framework that will allow you to write and execute testing of any web site or web application. In this first article, I want to discuss what that actually is and how the idea of creating one can be more daunting than it needs to be.

Wikipedia defines a framework as:

“In computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software. A software framework provides a standard way to build and deploy applications. A software framework is a universal, reusable software environment that provides particular functionality as part of a larger software platform to facilitate development of software applications, products and solutions. Software frameworks may include support programs, compilers, code libraries, tool sets, and application programming interfaces (APIs) that bring together all the different components to enable development of a project or system.”

While that might seem like a lot of jargon and buzz words to wrap your head around, I’m going to try and break it down in to something a bit less daunting. Ultimately, when you’re tasked with creating a framework, for automation or otherwise, it would be easy to imagine writing super technical code and having all kinds of clever and complicated things going on and it being far beyond your capability unless you’re a coding veteran. But really, it isn’t like that at all.

In job specifications for automation based roles, it’s quite common to see phrases like “Experience of writing test frameworks from scratch” or “Comfortable designing test frameworks or working with existing in-house frameworks”. But these phrases can mean so many different things, and quite often, the person writing the job spec has no idea themselves of what a framework actually is, they just know they need one for their automation testing. And because of this, there is no right way or wrong way way of writing a test automation framework. Sure there are bad ways, there are really bad ways of writing a framework, but it doesn’t make it wrong. The most important element of any framework in this context is that it supports and allows the execution of test automation scripts.

When I was first asked to create an automated framework from scratch on my own, I was terrified. I mean I knew exactly what was needed for automated tests to work, but surely I’d be needing to be on a senior developer level code wise to be able to do this? Well actually no, I couldn’t have been more wrong. And while, the framework I created was far from perfect, and could be considered “poor” in terms of design, it did the job and was supporting the writing of test scripts. Since then, I’ve moved from company to company, and while design patterns (such as Page Object Model design) might be the same, no framework has ever looked remotely similar because everyone has their own idea of what a framework should be.

See a framework at it’s most basic level can be a single code project full of classes, or even a single class that consists of common components that you will be using to write tests and allow you to separate your test code and, using Selenium as an example, Driver code, as much as possible. Depending on how complex your automation requirements are, your framework can be as big or as small as you like.
It’s too easy to get caught up in the idea that a framework should contain everything from front end testing capability, backend testing capability, database reading and writing, CSV file reading and writing, remote and local testing, custom reporting and so on, but if your requirements say that all you want and need to do is run a few end to end tests in a simple web based UI, well then why would you bother with the overhead of having all that in a framework when it’s never being used?

Other definitions will say that users shouldn’t be able to modify it, that extending it is allowed but modifying it should not. The idea that it should be separate from the tests or packaged so that the test writer never sees the code itself, just uses the code it implements. But lets look at that statement for a second… Using Selenium as an example again, the above statement can be applied and is completely true. You’re effectively downloading .dll files to your solution which you will reference, and you can’t modify but, with the use of extension methods, we can add methods to the capability of Selenium. But this doesn’t have to be true of a framework that you will write, especially if you’re the only one using it which is often the case in small software houses.
As I explained earlier, a framework can be as little as a single class with some methods that wrap common actions in to simple methods that will be used throughout your tests, so if that single class lives within the same project as your tests, then so be it. And while this wouldn’t be considered good design, it wouldn’t take away from the fact that for the purposes of automation, it could be considered a “framework”.

On the flip side, you could write many layers of abstraction to make the writing of tests so simple that your framework will consist of many classes, possibly across multiple namespaces and even across multiple projects. But to reaffirm my point, that doesn’t make it any more of a framework than the first example with a single class. Both of those will allow test scripts to be executed, and if that was the only requirement, it’s up to you how simple or complicated you want it to be.

So, after all that I hope that you feel a bit more comfortable with the idea of a framework, and hopefully feel more confident that actually you are more than capable of writing one. And by the end of this series of articles, you will have exactly that. A working framework that you can use how you see fit! I’m so excited at the prospect of helping you build your knowledge of automation and hopefully ensuring your ambition, which brought you here, will be rewarded!