*
Quick Links|Home|Worldwide
Microsoft*
Search for


Pex – Parameterized Unit Tests

Traditional Unit Tests

A unit test is a procedure to check that a particular feature works correctly.

For example, the following unit test checks that when two different objects are inserted into a hashtable at two different indices, they can be looked up again and will still be different.

    [TestMethod] 
    void HashTest() {
        Hashtable h = new Hashtable();	
        h[1] = new object();
        h[7] = new object();
        Assert.IsTrue(h[1] != h[7]); 		
    }
        

Writing such a test involves:

  • Determining a meaningful sequence of method calls,
  • selecting exemplary argument values (test input values),
  • stating assertions.
Parameterized Unit Tests

A parameterized unit test is very similar, but it does not fix all values that appear in the test. Some values may be supplied as parameters of the test. (In some contexts, such tests are called data-driven tests.)

For example, the following parameterized unit test checks the same property as the test above, but it does not fix the concrete index values.

    [PexMethod]
    void HashTest (int key1, int key2) {
        Hashtable h = new Hashtable();
        h[key1] = new object();
        h[key2] = new object();
        if (key1 != key2)
            Assert.IsTrue(h[key1] != h[key2]);
    } 
	    
Test Input Generation

Pex can automatically generate inputs for parameterized unit tests. Inspired by the tool DART, Pex tries different test inputs in a feedback loop.

Pex will execute the test with different test inputs. Every time Pex executes the test, Pex monitors the execution closely. Pex records the taken execution path and all interactions the test has with the environment.

At first, Pex executes the test with random test inputs. Using a constraint solver, Pex determines new test inputs using information from the recorded previous execution paths. In a nutshell, Pex' constraint solver attempts to find inputs which will not cause any of the previous execution paths to be taken again. Pex repeats this input-finding process. Since the number of execution paths in a program can be infinite, the process might not terminate. To this end, the user can set various bounds to limit the scope of the exploration.

This systematic exploration of the execution paths yields a small test suite with high code coverage.

Pex can generate inputs for all .NET data types, and Pex can synthesize the behavior of mock-objects.

Next


©2008 Microsoft Corporation. All rights reserved. Terms of Use |Trademarks |Privacy Statement