Enterprise Meta API Test framework


    Another concept that I find very useful is the CookieCutter. I saw it in puppet architecture and in Python, But that's not all - C, C++, JS, HTML .... the list can become very long. Even the uses may defer greatly, the core is all the same - utilize the creation of environments/projects from cookiecutters (templates), e.g. creating a Python package project from a Python package project template. Do it right and it's Cross-platform too. 

    The Test harness by definition is "a collection of software and test data configured to test a program unit by running it under varying conditions and monitoring its behavior and outputs". It's said that it has "two main parts: the test execution engine and the test script repository". A quick look at the test execution engine will give us the concept we're after here: separation of execution, specification and data. This what our CookieCutter will provide. In order to achieve it, we'll need the help of some powerful version control such as GitHub. A working solution is to keep the parts of our abstraction in separate Test projects. How all this will work ?!? The Git will provide us with branching of the projects and the code that we'll reuse. Put in simple words - every newly created projects will have to be a branch of already provided ones. The re-usability will be very easy too - just branch the project you need and start using it. I know that this solution is tight coupled, but a well skilled team will have no problems pulling this through. And the advantages are more than the shortcomings. Enough talking....

     Let's start building up the skeletons. Since we require granularity of the Test harness, the first Test projects will be .Core and .Tests . The .Core will be a container for our test execution logic, respectively the .Tests will be responsible for our tests. The .Utils can be created to support the Test data generation.     

    The next big "system" is the operating test logic. By design we support test project for every module. So if we'll have some integration (or want to reuse something) this can be done via branching the one project we need. Big benefit will be that the code will come alongside with the configuration it's needs to run. And it's supported by the person who is keeping it "alive" every day. Each Module.Core test project will be utilized as separate sub-module git repo. 

    The combo of technologies I'll use may not be a perfect fit for some particular case, but I had a chance of working with them (all together) and the results were good. The solution foundation will be on top of the .Net framework, so my choice is as follows:

- log4net is a tool to help the programmer output log statements to a variety of output targets. log4net is a port of the excellent Apache log4j™ framework to the Microsoft® .NET runtime. 
- Specflow  is open source and provided under a BSD license. As a part of the Cucumber family, SpecFlow uses the official Gherkin parser and provides integration to the .NET framework, Silverlight, Windows Phone and Mono.
- Autofac  is an Inversion of Control container for .NET 4.5, Silverlight 5, Windows Store apps, and Windows Phone 8 apps.
- NUnit NUnit is a unit-testing framework for all .Net languages.
- StyleCop  analyzes C# source code to enforce a set of style and consistency rules. It can be run from inside of Visual Studio or integrated into an MSBuild project. StyleCop has also been integrated into many third-party development tools.
- NuGet  is the package manager for the Microsoft development platform including .NET. 
- Rand generator 
- dbAccessor
- wintellect powerscollections
- abstract factory

    Code implementation is separated in MetaApiTestFramework.CookieCutter project and MetaApiTestFramework.Core. The first one is also split in .Core, .Tests and .Utils. They all contain the test logic and configs that are needed to setup any newly created ApiTest project. All unique modules/services that require it's own Test project must live in separate Git repo. This architecture enforces reusability and separation of the Test engine, specification and data. 



No comments:

Post a Comment