Enterprise Meta API Test framework
Enterprise Meta API Test framework
Learn the details about the Meta API Test Framework, and how it helps software development and testing in general.
Join the DZone community and get the full member experience.Join For Free
In response to accelerated release cycles, a new set of testing capabilities is now required to deliver quality at speed. This is why there is a shake-up in the testing tools landscape—and a new leader has emerged in the just released Gartner Magic Quadrant for Software Test Automation.
I've been looking at the meta-framework concept from a long time now. The first glimpse was related with the Continuous delivery, but very soon it became more than just an artifact. The abstract layer can give a lot, but also take a lot. If you're aiming to adopt the meta paradigm, then do it right. Very useful information on conceptual level can be found in this great article.
So far based on my experience I have two completely (hmm...but are they ?!?) implementations of such Meta API Test Framework. Both powered by diverse technologies and yet diverse methodologies.
First one is monolithic, modelling and unifying - an Enterprise edition. The clear advantages are coming from all it's characteristics already mentioned, but if we'll stick to simple -it's complete unified process. Take a look at Enterprise application integration.
At this point I'll stop at the point of describing the second implementation with just this - (high) abstraction packaging.
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 along side 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
- wintellect powerscollections
- abstract factory
Code implementation is separated in MetaApiTestFramework.CookieCutter project and MetaApiTestFramework.Core. The first one is also splited 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 arhitecture enforces reusabilty and separation of the Test engine, specification and data.
Opinions expressed by DZone contributors are their own.