How to build your test automation framework
Foundation Framework
A Foundation Framework is built prior to any application that are built on top of it.
The idea is that you analyse the needs of the various applications that need the framework, then you build the framework.
Once the framework is complete you then build applications on top of it.
The point is that the framework really needs to have a stable API before you start work on the applications, otherwise changes to the framework will be hard to manage due to their knock-on effects with the applications.
While this sounds reasonable in theory, I've always seen this work badly in practice.
The problem is that it's very hard to understand the real needs of the framework.
As a result the framework ends up with far more capabilities that are really needed.
Often its capabilities don't really match what that the applications really need.
Harvested Framework
To build a framework by harvesting, you start by not trying to build a framework, but by building an application.
While you build the application you don't try to develop generic code, but you do work hard to build a well-factored and well designed application.
With one application built, you then build another application which has at least some similar needs to the first one.
While you do this, you pay attention to any duplication between the second and first application. As you find duplication, you factor out into a common area, this common area is the proto-framework.
As you develop further applications each one further refines the framework area of the code.
During the first couple of applications you'd keep everything in a single code base.
After a few rounds of this the framework should begin to stabilize and you can separate out the code bases.
While this sounds harder and less efficient than Foundation Framework, it seems to work better in practice.
A Foundation Framework is built prior to any application that are built on top of it.
The idea is that you analyse the needs of the various applications that need the framework, then you build the framework.
Once the framework is complete you then build applications on top of it.
The point is that the framework really needs to have a stable API before you start work on the applications, otherwise changes to the framework will be hard to manage due to their knock-on effects with the applications.
While this sounds reasonable in theory, I've always seen this work badly in practice.
The problem is that it's very hard to understand the real needs of the framework.
As a result the framework ends up with far more capabilities that are really needed.
Often its capabilities don't really match what that the applications really need.
Harvested Framework
To build a framework by harvesting, you start by not trying to build a framework, but by building an application.
While you build the application you don't try to develop generic code, but you do work hard to build a well-factored and well designed application.
With one application built, you then build another application which has at least some similar needs to the first one.
While you do this, you pay attention to any duplication between the second and first application. As you find duplication, you factor out into a common area, this common area is the proto-framework.
As you develop further applications each one further refines the framework area of the code.
During the first couple of applications you'd keep everything in a single code base.
After a few rounds of this the framework should begin to stabilize and you can separate out the code bases.
While this sounds harder and less efficient than Foundation Framework, it seems to work better in practice.
0 Response to "How to build your test automation framework"
Post a Comment