# Sunday, October 25, 2009

I’ll be presenting Stubs and Moles at the Visual Studio User Group on November 3rd. See you there…

Stubs is a lightweight framework for test stubs and detours in .NET that is entirely based on delegates, type safe, Refactorable, debuggable and source code generated.
Stubs also allows to replace  any .NET method with a user-defined delegate, including non-virtual/static methods in sealed types. Stubs is fully integrated into Pex , an automated white box test generation tool for .NET.
http://research.microsoft.com/en-us/projects/stubs/

posted on Sunday, October 25, 2009 2:45:44 AM (Pacific Daylight Time, UTC-07:00)  #    Comments [2]
# Thursday, October 22, 2009

We’ll be hosting a booth and a Session with Code Contracts at the PDC’09 conference.

Code Contracts and Pex: Power Charge your Assertions and Unit Tests
Come hear how Code Contracts provides a set of tools for design-by-contract programming and how Pex is an advanced unit-testing tool that uses automated program exploration to intelligently create unit tests with high code coverage. See how they work together so that your code has fewer defects. Learn about new features for Code Contracts including automatic documentation generation, call-site checking for components and reference assemblies for the .NET Framework and for Pex including a light-weight mocking framework, improved support for large code bases, and more thorough test input generation.

posted on Thursday, October 22, 2009 7:14:52 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]
# Friday, October 16, 2009

If you have the chance to attend Tech Europe, don’t forget to attend our session on Code Contracts and Pex . Nikolai Tillmann and I will also be attending a booth (on Code Contracts and Pex) during the week. See you there.

DEV315 Code Contracts and Pex: Power Charge Your Assertions and Unit Tests
Friday 11/13 – 13:00pm – 14:15pm.

posted on Friday, October 16, 2009 5:23:51 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]
# Wednesday, October 07, 2009

We have just release a new version of Pex (v0.17.xxx) which brings new features for Moles and more bug fixes.

Per-Instance Moles

Instance methods may be moled differently per object instance. This is particularly useful when multiple instances of same type need to behave differently in the same test. For example, let’s consider a simple class Bar that has a ‘Run’ method to check that the values are not the same. The important point here is that we would not be able to deal with such cases if we could not mole the behavior on a per-instance basis.

image

In the test case of Run, we create to instance of MBar (the mole type of Bar) and assign two different delegates to the ‘Value’ getter. Moles are active as soon as they are attached (unlike the previous version) so we can just call the ‘Run’ method once the moles are set up. In the code below, we are using the C# Object Initializers feature that allows us to set properties of a newly created object within curly braces after the ‘new’ call.

image

As you may have noticed, we just wrote a parameterized unit test that takes arbitrary ‘left’ and ‘right’ values. We then simply execute Pex to find the relevant values to cover the ‘Run’ method:

image

Moles for Constructors

In same cases, objects created inside of other methods need to be moled to test the actual program logic. With moles you can replace any constructor with your own delegate, which you can use to attach a mole to the newly created instance. Let’s see this with another simple example where a  ‘Run’ method creates and uses an instance of a ‘Foo’ class.

image

Let’s say we would like to mole the call to the ‘Value’ property to return any other value. To do so, we would need to attach a mole to a future instance of Foo, and then mole the Value property getter. This is exactly what is done in the method below.

image

We then run Pex to find that 2 different values are needed to trigger all code paths.

image 

Mole interface binding

All the member implementations of an interface may be moled at once using the new ‘Bind’ method. This smells like duck typing with type safety as the Bind methods are strongly typed. For example, we want to mole a collection type (Foes) to return a custom list of Foo elements (which need to be moled too). The goal is to test the sum method…

image

In the parameterized unit test case, we create an instance of Vector, which implements IEnumerable<int>. Then, we can simply bind the ‘values’ array to the mole to make Vector iterate over the array. The call to Bind will mole all methods of MVector that are implemented by the ‘values’ parameters, effectively redirecting all the enumeration requests to the ‘values’ array.

image

When Pex runs through the sample, it correctly understand the data flow of the parameters through the moles and finds inputs that break the ‘sum >= 0’ assertion:

image

Compilation of Stubs assemblies

When one needs stubs or moles for a system assembly, it does not really make sense to re-generate the stubs each time the solution is loaded. To that end, Stubs ships with a command line tool that lets you easily compile a stubs assembly into a .dll:

stubs.exe mscorlib

Once the stubs assembly is compiled, i.e. mscorlib.Stubs.dll is created, you simply have to add a reference to it in your test project to start using it. In future versions of Pex, we will provide a better experience to support this scenario.

Bug Fixes

Breaking Changes

  • The code generation of Moles was significantly changed. This might mean that you will have to recompile your solution, and adapt all existing uses of Moles.
posted on Wednesday, October 07, 2009 3:02:46 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]