Preparing your result...
Loading...
Press Esc to dismiss this message

Test Authoring And Execution Framework (TAEF) Excution Model (24-Feb-2009)

Thumbnail
IP.com Prior Art Database Disclosure (Source: IPCOM)
Disclosure Number IPCOM000179732D dated 24-Feb-2009
Originally published in Prior Art Database
Disclosed by: Microsoft
Country: Undisclosed
Copyright: Copyright Microsoft 2009
Related People
Frank Gorgenyi - INVENTOR [+3] [-3]
FRANKGOR@microsoft.com
Mark T. Schofield - INVENTOR
MSCHOFIE@microsoft.com
Jared E. Henderson - INVENTOR
JAREDH@microsoft.com
Benjamin J Kuhn - INVENTOR
BENKUHN@microsoft.com
Disclosure File: 7 pages / 82.0 KB / English (United States)

A Test Authoring and Execution Framework (TAEF) model is provided that allows software developers to execute multiple tests of code through a single framework. Unlike previous solutions that require separate test harnesses for each technology used to implement the code being tested, the present solution uses a test engine and separated plugin pairs to allow a single test engine to drive tests written using a variety of technologies. The first class of plugins operate within the engine to read metadata and determine the testing necessary. The second plugin class, which are respectively paired with members of the first class, invoke the specific test or tests needed, so that the environment may be changed as the tests require.

This text was extracted from a Microsoft Word document.
This is the abbreviated version, containing approximately 26% of the total text.

Test Authoring and execution Framework (TAEF) Execution model

The enterprise of software development has become a cumbersome one given the number and complexity of different avenues that are currently available for implementing any given component.  There are a great number of programming languages which may be used for executing a particular module.  For example, C, C++, C#, Perl, Python, Javascript™, and VBscript are a small set of the numerous common languages used for development.  In addition, there are various platforms and architectures that may be used to execute those instructions.  For instance, programs may be intended for Component Object Model (COM), Dynamic Language Runtime (DLR), or native Win32 execution on several architectures, such as x86 systems, 64-bit architectures, and so forth.  Finally, there are different types of tests that must be run, creating yet another layer of complication.  The appropriate testing tool may depend on whether the test is specific to unit, scenario, or high-level testing.  For the programmer that is involved with development across a spectrum of languages, architectures, interface standards, or testing types, this can require laboriously running and re-running tests on the different testing tools needed.  As examples, a developer may need to use an NUnit-compatible tool to test interactions with .net code (a managed code), JUnit for Javascript™ code, and xUnit for other code segments.  Thus, enabling a single tool to automatically test across these spectra would greatly enhance the overall testing process.

In order to meet programmers’ needs, a new testing harness has been developed that simplifies this process.  The Test Authoring and Execution Framework (TAEF) model allows a developer to program code that reaches across languages, platforms, or architectures, but that tests that code under one umbrella.  The framework includes a test engine that is executed with a pair of plugins to enable support for each applicable technology.  Previous solutions for multiple-technology testing carried with them certain environment-specific drawbacks.  Those tools did not give fully reliable testing as they initiated multiple tests in the same process.  The current invention avoids this with the plugin pairs that help invoke multiple testing tools in their own environments.  Thus, by using one plugin within the TAEF engine, and a second plug-in to actually invoke the necessary test, the previous drawbacks are eliminated.

Through the abstraction and analysis of metadata embedded in the code, plug-in pairs carry out a two-part process.  The first portion of this process centers on test discovery, while the second portion involves the test execution.  Intuitively, one half of each pair of plug-ins is responsible for discovery, while the other half handles execution.  Examples of test discovery mechanisms that can be used by the firs...

(Source: IPCOM)
First page image
(Source: IPCOM)