Before you start constructing your automation framework, you need to figure out what you are looking to achieve first, so you can then assess whether you have succeeded in the task later on. In the AGILE world, this is called defining your 'Definition of Done'.
Frameworks have a habit of growing organically and while this can be a great thing when it follows a design pattern, it can be horrible if it occurs randomly and without planning.
It essentially becomes the difference between an oak tree growing upwards towards the sky and something that is cancerous and growing out of control. One follows a pattern of behavior while the other is random and serves no benefit.
Lets write our 'statement of intent' - what we want to achieve with our framework.
'I want an automation framework that can be installed into a test project and allows the user to start writing automation code almost instantly with minimal setup involved. The framework should be modular and decoupled to facilitate maintainability. The framework will be built using .Net C# so our developers can use the same framework to write their Unit Tests. BA's currently write their specifications using the Gherkin syntax, so the framework will have Specflow at its heart to allow mapping of tests to requirements. The framework should promote a solution / project layout to help keep its users consistent in their approach.'
From the above statement we get:
- Must be a quick installation process
- Modular and decoupled
- Using .Net C#
- Using Specflow
- Framework promotes a pattern/layout
While these are by no means the only requirements we care about, these are the ones that will be required for our definition of done to be achieved. This is how we determine if our framework is ready for consumption.
Now that we have our needs or 'requirements' - we can start planning how we want to achieve these at a high level.
Requirement #1 could be achieved using Nuget packages for instance. Nuget packages allow you to attach example files, class files and documentation that will get installed into a project when the Nuget package is consumed. We could have a Nuget Package called 'Automation.Framework.Base' for example.
Requirement #2 could also be achieved using Nuget packages, but instead of packaging the whole framework, we would separate the individual pieces of functionality into individual Nuget packages. This means that updating one piece of functionality should not necessarily impact another area of functionality.
Requirement #3 is achieved simply by using C# as our language of choice. Training and documentation will be important if your QA staff are inexperienced in .Net C#.
Requirement #4 requires that we use Specflow for our BDD Language interpreter. By using C# we have eliminated Cucumber and other Gherkin BDD tools due to incompatibilities with C#. Specflow remains the logical choice for C# based test frameworks. Installing this is two fold - we need to install the Nuget Package for Specflow.NUnit.Runners as well as the Visual Studio Specflow extension. Without the extension, visual studio will interpret .feature files as text files.
Requirement #5 can also be facilitated through use of Nuget. A properly configured .nuspec file can create folder structures, create example files and setup app.configs seamlessly without requiring the user to provide input.
Our above statement has given us 5 requirements which can be solved through various tools and strategies.
The next post will delve into Visual Studio and show how to get started with our decoupled framework.