Automatic Unit Tests Generation and Implementation

This post is about generating tests automatically which would test the api's written by a developer with it's very first build. The idea is to generate tests which would run with the build process and report errors with subsequent changes to the code. This methodology makes sure that each and every api would be tested with all the basic negative tests that could be generated for the arguments used by the API. This could help the developer find bugs based on the permutations of inputs to the api, something tools like "AllPairs" do.

The other advantage of using it is that a properly compiled document about the API and tests cleared could be generated out of it. Another subtle usefulness of it could be making a standard way for developers to document their api's which would be useful to their successors and client programmers. Later white box testers could include their tests which would be listed in the help document created with every build.

Disclaimer - This methodology does not guarantee generation of tests covering 100% functionality of the API in question but would generate and implement code automatically.

Requirements:
Any scripting language (perl, tcl ...) for generating/implementing tests, invokable in Visual Studio or any prefered IDE.
Unit Test framework (JUnit, CppUnit, NUnit ...) for running the tests and reporting the results back.
Updation of three xml files namely "Api.xml", "Types.xml", "Minimalobjects.xml" and "TestsCollection.xml".

The first three documents are updated by the developers and the last one is modified/updated by the script and whitebox testers. Now lets look at the structure of the "Api.xml" file, this structure might not be adequate for everyone but could be modified to suit the requirements.
click on the image to see the content clearly

Now lets examine what the above xml means and how would it be useful to us. This xml file is a store of Api's written used in the solution. This would contain all the api's written along with the relevent information as described below:

"name" and "author" attributes are for denoting the name of the Api and the author, more attributes such as "module => shading / filling", "excutes (remote/local)" for clarity in documentation.

"Description" is for describing the functionality of the Api.

"Arguments" contains all the arguments the api takes. This could be processed recursively and test generated accordingly.

In arguments "type" attribute describes the type of argument. "Description" is the info about that argument. Print value and help link are purely for Documentation purpose and can be extended accordingly.