Share this page
Pex - Release Notes

v0.19.41110.1, 11/12/2009

  • Better Dev10 Beta 2 support! We’ve upgraded our support for Visual Studio 2010 Beta 2. This includes full support for .NET 4.0 Beta 2, the Visual Studio Unit Test HostType and the Visual Studio integration.
    Known Beta 2 issues: 1) When running Pex for the first time, the path to Visual Studio Unit Test is not found. You need to specify the Visual Studio ‘PublicAssemblies’ path (“c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies”), 2) Don’t run Pex on v2 projects, Pex will crash.
  • Smooth generation of Stubs and Moles: when you create a stubs and moles assembly that is not a project reference, like one of the system assemblies, the stubs and moles code generator will automatically compile it into an assembly and add it to the project. This dramatically increases the performance of projects using Stubs and Moles.
  • Stubs and Moles for VisualBasic.NET: the Stubs and Moles may be used in VisualBasic.NET projects. In that case, they are embedded as a compiled assembly.
  • Moles support for NUnit, xUnit.Net and others: Unit tests involving Moles require the Pex profiler to work. We’ve added a new mode to our command line runner that allows to execute your favorite unit test framework runner under Pex. For example, the command “pex /runner=xunit.console.exe tests.dll” will launch the xunit runner for test.dll under Pex. x64 assemblies are still not supported.
  • Nicer Moles Syntax: we’ve added some little tweaks to the Moles API, such as an implicit conversion operator to the moled type, that simplifies the syntax. Here is a small example that showcases the current syntax: step 1 moles the Bank constructor, step 2 moles the GetAccount method and returns a mole of Account, step 3 moles the getter and setter of the Balance property.
  • Fluent Mole Binding: The Bind method returns the mole itself which allows it to be used in a fluent fashion. Interface binding is specially useful when you need to mole custom collections – just attach an array! For example, we attach an array of integers to a the MyList type that implements IEnumerable<int>.
  • Breaking Changes in Stubs and Moles:
    • The stubs and moles code generator tool is now ‘StubsGenerator’. You need to path this value in the property pages of your .stubx pages.
    • No more AsStub and AsMole: the AsStub and AsMole helpers were confusing and pretty useless so we decided to reduce the amount of generated code by removing them.
    • The naming convention for Stubs delegate fields always mangles the parameter types of the stubbed method, i.e. Foo(int) yields to a field called FooInt32. We used to be smart about adding parameters but we decided to make the scheme stable and symmetric with respect to the Moles.
    • The ‘FallbackBehavior’ property has been renamed to ‘InstanceFallbackBehavior’ in both Stubs and Moles to make it more explicit.

v0.18.41014.0, 10/14/2009

  • New Tutorials: Stubs and Moles, and Unit Testing SharePoint with Pex: If you felt that you didn’t know how to get started with Stubs, Moles, and Pex, then you will like the following two tutorials. They are bundled in the Pex installer, and you can also get them from our website:
  • Moles for Visual Studio 2010: The [HostType(Pex)] attribute, which is required to execute generated, or hand-written parameter-less test cases that Moles, now also works with unit tests in Visual Studio 2010.
  • Breaking Changes: The code generation of Moles has changed again. This might mean that you will have to recompile your solution, and adapt all existing uses of Moles.
  • Bug Fixes

    • v0.17.41006.7, 10/07/2009

    • 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.

      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.

      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.
    • 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.

      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.

      We then run Pex to find that 2 different values are needed to trigger all code paths.
    • 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.

      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.

      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.
    • 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.

    v0.16.40915.5, 09/15/2009

    • Moles, a lightweight detour framework: Moles is a new extension of the Stubs framework: it lets you replace any .NET method (including static methods) with your own delegate. Because an example is worth more than a thousand words, here is snippet that shows how to make a static method (in this case, WCF OperationContext.Current) return a predefined value:

      Want read more about this sample? here is the full walkthrough.
      The moles framework is not yet feature complete; moles does not support constructors and external methods. Some types of mscorlib cannot be moled as they interact too deeply with the CLR. 
    • Pex gets its own HostType: A HostType is a feature for the Visual Studio Unit Test framework that lets specific unit tests be run under specialized hosts such as Asp.Net or VisualStudio iself. In order to create reproducible test cases using Moles, we had to implement a HostType that lets tests be run under the Pex profiler. This is very exciting because it also opens the door for many uses of Pex such as fault injection, dynamic checking, etc… in future versions of Pex. When generating test cases with Pex, all the necessary annotations will be created automatically. To turn the Pex HostType on hand-written (non-parameterized) unit tests, simply add [HostType(“Pex”)] on your test case.

      This feature only works with Visual Studio Unit Test 2008.
    • Select your test framework: the first time you invoke ‘Pex’ on your code, Pex pops up a dialog to select your test framework of choice. You can select which test framework should be used by default and, more importantly, where it can be found on disk.

      If you do not use any test framework, Pex ships with what we call the “Direct test framework”: in this “framework”, all methods are considered as unit tests without any annotation or dependencies.

      These settings are stored in the registry and Pex should not bug you again. If you want to clear these settings, go to ‘Tools –> Options –> Pex –> General’ and clear the TestFramework and TestFrameworkDirectory fields:
    • Thumbs up and down: We’ve added thumbs up and down buttons in the Pex result view. We are always looking for feedback on Pex, so don’t hesitate to click them when Pex deserves a thumbs up or a thumbs down.
    • Performance: Many other performance improvements under the hood which should avoid Pex hog too much memory in long running scenarios.
    • Miscellanous improvements and bug fixes:
      • Support for String.GetHashCode(): we now faithfully encode the hashing function of strings, which means Pex can deal with dictionaries where the key is a string.
      • Fewer “Object Creation” messages that are not actually relevant.
      • In VS 2010, the package used to trigger an exception when the solution loaded. This issue is now fixed.
      • In Visual Studio when an assembly had to be resolved manually (i.e. that little dialog asking you where an assembly is), Pex remembers that choice and does not bug you anymore. 
      • Test project may be renamed before being saved.
      • The exploration context is not lost when the build breaks.
      • And many other bugs that were reported through the forums.

    v0.15.40714.1, 07/15/2009

    • Better memory management and bug fixes. A lot of issues reported in the MSDN forums were fixed.
    • Breaking changes: Microsoft.Pex.Stubs.dll does not exist anymore and has been integrated into Microsoft.Pex.Framework.dll, PexExplorableFromFactoriesAttribute renamed to PexExplorableFromFactoriesFromAssemblyAttribute

    v0.14.40610.2, 06/11/2009

    • Fix Suggestions for Invariant Methods: When you use Code Contracts, then Pex can now help you to add missing invariants, just as Pex already inferred missing preconditions in the past. Take for example the ArrayList class that comes with the samples of our recently updated tutorial slide deck. This class has the following fields:

      When you add an empty invariant method,

      and enable Runtime Checking of contracts, then Pex will create instances of this class using reflection while making sure that the invariants holds. However, with an empty invariant method, Pex will be able to create illegal states, e.g. where the _items array is null, which may cause a NullReferenceException, and other issues. To get the following test cases, we let Pex explore the Add method of our ArrayList class:

      When you look at the details of the failing test cases, then you will see that Pex now offers the option to add invariants directly into your [ContractInvariantMethod]:
    • Natural Properties for Stubs: The logic to handle properties with setters and getters generated by Stubs has been slightly improved so that it is possible to force properties to have as if they had a backing field.
      When a getter or a setter of a property is invoked, Stubs checks whether the getter delegate or the setter delegates have been set. If not, i.e. no custom user behavior, it queries the fallback behavior for an initial value of the property. If the fallback behavior successfully returns a value, Stubs generates a closure and binds the getter and setter.
      For example, here’s a simple IFoo interface with a Bar property:

      One could write the following parameterized unit test:

      Since we expect the Bar property to behave as it was wrapping a field, we don’t expect the assertion to be raised. When we execute this test with Pex, and the Pex fallback behavior, Pex will choose a value for ‘Bar’, and this value will be ‘stored’ the property. Therefore, we get as expected 2 test cases:
    • Non default constructor support for Stubs: In previous versions, Stubs could not generate stubs for classes with no default constructor. This is no longer the case, Stubs will generate one public constructor for each public or protected base constructor.
    • Bug Fixes
      • Various code generation tweaks to make StyleCop happier
      • Visual Studio addin crashes when loading in VS201
      • Visual Studio addin does not find attributes when they are globally qualifie
      • Added missing substitutions for System.Threading.Interlocked member
      • Stubs automatically imports missing reference
      • When an object has an invariant method (from Code Contracts), Pex would emit assertions using the private field
      • Editorial issues to patterns pape
      • Contracts no longer kill the process when the runtime rewriter was not executed (.net 4.0
      • Fixed bug in generic type guesser
      • Fixed samples for the latest version of Stubs

    v0.13.40528.2, 05/28/2009

    • Seeding the Exploration Part 1: Unit Tests as Inputs

    Before using heavy-weight constraint solving to explore hard-to-reach execution paths, Pex can now leverage already existing unit tests that call a parameterized unit tests: Pex scans their body to extract the parameter values, and then Pex uses these values to seed the exploration. (In the past, Pex would have seeded the exploration by simply using the default values for all parameters, and nothing else.)

    Here is an example, where Pex starts the exploration of the parameterized unit test Multiply by reusing the values mentioned in the unit test MultiplySeed, as you can see in the first row of the table of generated tests.

    As a (intended) side effect, Pex also reuses the tests that Pex might have generated during earlier explorations. In effect, Pex never has to start from scratch again, but instead can reuse knowledge from earlier explorations.

    There is a big limitation in this first version of the new feature: Pex can only use values of primitive types, and arrays of primitive types as seeds, and the values must be passed as parameters, not via PexChoose. The unit tests must be in the same class as the parameterized unit test, marked as a unit test, and have a simple structure, i.e., they must just create the input data, and the first method call must be to a parameterized unit test.

    • Seeding the Exploration Part 2: [PexArgument(…)] to Fuzz Inputs and Help Pex

    Pex can not only extract values from existing unit tests, but there is in fact a general API through which seed values can be given. In particular, you can use the new PexArgumentAttribute (and a bunch of related new attributes) to provide seed values.

    Here is an example:

    During the subsequent exploration, Pex will often reuse parts of the seeded values, which may make constraint solving easier for Pex. Also, when Pex cannot solve all constraints to leap beyond a difficult branch, then you can use this feature to help Pex by providing the values yourself.

    • Object Creation with Invariants

    Code Contracts enable the specification of class invariants by writing an “invariant method” decorated with the ContractInvariantMethod attribute. For example, for a typical ArrayList implementation, this invariant method might read as follows:

      public class ArrayList { 
        private Object[] _items; 
        private int _size; ... 
        [ContractInvariantMethod] // attribute comes with Code Contracts
        protected void Invariant() { 
          Contract.Invariant(this._items != null); 
          Contract.Invariant(this._size >= 0); 
          Contract.Invariant(this._items.Length >= this._size); 
        }
     

    If you have such an invariant, and if you correctly configure runtime checking of contracts, then Pex will create instances of this type by first creating a raw instance, setting all private fields directly, and then making sure that the invariant holds. A generated test case for the Add method of the ArrayList class might then read as follows:

      [TestMethod]
      public void Add01() { 
        object[] os = new object[0]; 
        // create raw instance
        ArrayList arrayList = PexInvariant.CreateInstance<ArrayList>();  
        // set private field via reflection 
        PexInvariant.SetField<object[]>(arrayList, "_items", os); 
        PexInvariant.SetField<int>(arrayList, "_size", 0);        
        // invoke invariant method via reflection
        PexInvariant.CheckInvariant(arrayList);                   
        // call to method-under-test 
        arrayList.Add(null); 
      }
     

    A limitation of the current implementation is that the type itself must be public, and the types of all fields must be public (but not the fields themselves.)

    • Surviving unhandled exceptions in Finalizers

    Finalizers are especially problematic for test runners: there is no guarantee from the runtime when they will be executed, and when they throw an exception, the process terminates. This is not an uncommon scenario when you apply Pex to (buggy) code with Finalizers: It seems as if Pex suddenly crashes.

    In this version, we have improved the robustness of Pex with respect to those failures. Pex effectively rewrites all finalizers of instrumented types with a catch handler that swallows all exceptions and sends it to Pex’ logging infrastructure.

    • Visual Studio 2010 Beta 1 support

    We’ve updated Pex for Visual Studio 2010 Beta 1, the latest Code Contracts version and F# Beta 1.

    • Send Feedback at your fingertips

    We made it even easier for you to ask questions about Pex, or to just tell us what you think, right from Visual Studio:

    • Bug fixes and other small features
      • The Stubs framework generates stubs for types containing obsolete members. This behavior can be disabled.
      • The wizard can generate tests for inherited members by adding the /gim flag or from the wizard settings/options.
      • The default test assembly name suffix string, i.e., the suffix used to generate the test assembly name, can be specified on the wizard command line, e.g. /tans:.PexTests, or in the Visual Studio options (Tools –> Options –> Pex –> Wizard –> Test Assembly Name Format String).
      • int ChooseIndexValue<T>(string, T[]) was added to the choice API to choose valid index values.
      • We added new overloads in PexAssume/PexAssert that support IEnumerable<T>, i.e. for AreElementsEqual etc…
      • Better understanding of _.GetType(), and conditions involving System.Type values.
      • The Stubs framework can assign values to ref parameters.

    v0.12.40430.3, 05/01/2009

    • Exploration Tree View: The exploration tree view displays the list of explorations to be executed, running and finished. It serves as a progress indicator but also as a smooth result explorer. When browsing through the tree, Pex will synchronize the exploration result view and the tree view.
      The tree view populates each namespace with the fixture types and exploration methods, and provide a visual feedback on the progress of Pex.

      When you browse through the exploration and generated test nodes, Pex automatically synchronizes the exploration result display. This makes it really easy to start from an high-level view of the failures and drill into a particular generated test, with stack trace and parameter table.
    • Partial Stubs: Stubs lets you call the base class implementation of methods as a fallback behavior. This functionality is commonly referred as Partial Mocks or Partial Stubs and is useful to test abstract classes in isolation. Stubs inheriting from classes have a “CallBase” property that can turn this mode on and off.
      Let see this with the RhinoMocks example on partial mocks. Given an abstract ProcessorBase class,

      we write a test for the Inc method. To do so, we provide a stub implementation of Add that simply increment a counter.
    • Miscellaneous:
      • PexAssume/PexAssert.EnumIsDefine checks that a particular value is defined in an enum.
      • Missing OpenMP assemblies in the installer.

    v0.11.40421.0, 04/21/2009

    • Known issues 

    • Delegate As Parameters: Pex now understands Parameterized Unit Tests that take delegates as parameters. Pex will automatically generate a delegate instance and its behavior: if the delegate returns a value, Pex will generate a new symbolic value for it, track its use, and then generate different values depending on the program behavior. Let’s consider a simple method to illustrate this new feature. I wrote the following Parameterized Test method which takes a Func<int> delegate and throws an exception if the delegate returns a particular value:

      When executing Pex on Test, Pex will generate a Func<int> which ‘asks’ Pex to choose the returned int (it uses PexChoose under the hood). Therefore, for each call to that delegate, Pex has the liberty to return a diferent value. Based on how it is used, Pex will generate different values to increase coverage. In this case, Pex ‘chooses’ to return 123 on the first call, which is exactly what we need to cover the exception branch. The following code is generated by Pex; it starts by setting up the desired values, and then it calls the parameterized unit test.
    • Pex Explorer: Exception Tree View: We have started to work on improving the experience when applying Pex to a large number of explorations. To this end, a new window called Pex Explorer will show various views over the events produced by Pex. The Exception Tree View provides the tree of exception types that Pex found. This is really helpful to quickly drill through the (really) bad exceptions first.
    • Pex Explorer: Contract Failures Tree View: If you are using Code Contracts, Pex also provides a specialized view to sort the contract failures kind.
    • Events in Stubs: Stubs now support events:the stub simply expose the backing delegate fields (which hold the event delegate)as a public fields. As a result, one can clear, set, and invoke the event as any other member. Let’s see this with an example:

      In order to raise the SomeEvent in a test, we would simply have to invoke the backing delegate field, which happens to have the same name as the event:

      It’s that simple.
    • Recursive Stubs: Another common feature of mock/stub frameworks is to support nested invocation of members. Stubs now lets yourecursively invoke property getters. Instead of assigning the property getter delegate, you can usenew helper methods ending in ‘AsStub’ thattake care of allocating thenested stub, assigning it to the property getter and returning it. Let’s see this with an example: assume we want to test the little snippet below.

      In order to set up our stub, we would need to have IParent.Child return a stub of IChild, then set up IChild.Name to return ‘joe’. For property getters, Stubs generates a helper method that does just that:

      The ChildGetAsStub call instantiated a SIChild instance, assigned to the Child property and returned it. It’s that simple.
    • Fixed Bugs
      • .Stubx fail to generate the stubs. We fixed a bug with the registration of Stubs in Visual Studio.
    • Breaking Changes
      • Microsoft.Stubs.dll has been renamed to Microsoft.Stubs.Framework.dll. The public Stubs type has been moved under the Microsoft.Stubs.Framework namespace.
      • The generated stub class names are built by prepending ‘S’ to the type name (‘IFoo’ –> ‘SIFoo’). In the previous version, the ‘I’ of interface name was trimmed which sometimes created name clashes.

    v0.10.40408.0, 04/10/2009

    • Known Issues
    • NUnit, MbUnit and xUnit.net supported out of the box: Pex now supports MSTest, NUnit, MbUnit and xUnit.net out of the box. Pex will automatically detect which framework you are using by inspecting the assembly reference list, and automatically save the generated tests decorated with the correct attributes for that framework.

      The default test framework can also be specified through the global options (Tools –> Options –> Pex –> enter the test framework name in TestFramework).
    • Writing Parameterized Unit Tests in VisualBasic.NET: While the Pex white box analysis engine works at the MSIL level, Pex only emits C# code for now. In previous releases, this limitation made it impossible to use Pex parameterized unit tests from non-C# code. In this release, we have worked around this problem by automatically saving the generated tests in a ‘satellite’ C# project. Let’s see this with an example. The screenshot below shows a single VisualBasic.NET test project with a Pex parameterized unit test:

      We can right-click in the HelloTest.Hello method and select “Run Pex Explorations”:

      At this point, Pex will start exploring the test in the background as usual. This is where the new support comes in: When a generated test comes back to Visual Studio, Pex will save it in a separate C# project automatically (after asking you where to drop the new project):

      The generated tests are now ready to be run just as any other unit tests!
    • Writing Parameterized Unit Tests from F#: Similarly to VisualBasic.NET, we’ve made improvements in our infrastructure to enable writing parameterized unit tests in F#. Let’s see this with a familiar example. We have a single F# library that has xUnit.net unit tests and reference Microsoft.Pex.Framework (project Library2 below). In that project, we add a parameterized unit test (hello_test):

      We can right-click on the test method name and Pex will start the exploration of that test in the background. Because of the limitations of the F# project system, you absolutely need to right-click on the method name in F# if you want contextual test selection to work. Because the project is already referencing xunit.dll, Pex will also automatically detect that you are using xUnit.net and use that framework. When the first test case comes back to VisualStudio, Pex saves it in a separate C# project:
      The tests are saved in the generated test project and ready to be run by your favorite test runner!
    • PexObserve: Observing values, Asserting values: We’ve completely re-factored the way values can be logged on the table or saved as assertions in the generated tests. The following example shows various ways to log and assert values:

      In the Observe method, we use the return value and out parameter output to automatically log and assert those values. Additionally, we add “view input” on the fly to the parameter table through the ValueForViewing method, and we add “check input” to be asserted through the ValueAtEndOfTest method. After running Pex, we get the following results:

      As expected, input, ‘view input’, output and result show up in the parameter table.

      In the generated test, we see assertions for the return value, out parameters and other values passed through the ValueAtEndOfTest method.
    • Code Contracts : Reproducible generated tests: When Pex generates a unit test that relied on a runtime contract, Pex also adds a check to the unit test which validates that the contracts have been injected into the code by the contracts rewriter. If the code is not rewritten when re-executing the unit test, it is marked as inconclusive. You will appreciate this behavior when you run your unit tests both in Release and in Debug builds, which usually differ in how contracts get injected.
    • Code Contracts: Automatic filtering of the contract violations: When Pex generates a test that violates a Code Contract pre-condition (i.e. Contract.Requires), there are basically two scenarios: the precondition was on top of the stack and should be considered as an expected exception; or it is a nested exception and should be considered as a bug. Pex provides a default exception filtering that implements this behavior.
    • Stubs: simplified syntax: We’ve considerably simplified the syntax of stubs by removing the ‘this’ parameter from the stub delegate definition. Let’s illustrate this with a test that stubs the ‘ReadAllText’ method of a fictitious ‘IFileSystem’ interface.
    • Stubs: generic methods: The Stubs framework now supports stubbing generic methods by providing particular instantiations of that method. In the following example, the generic Bar<T> method is stubbed for the particular Bar<int> instantiation:
    • Stubs and Pex: Pex will choose the stubs behavior by default: We provide a new custom attribute, PexChooseAsStubFallbackBehaviorAttribute, that hooks Pex choices to the Stub fallback behavior. To illustrate what this means, let’s modify slightly the example above by removing the stub of ReadAllText:

      If this test was to be run without the PexChooseAsStubFallbackBehavior attribute, it would throw a StubNotImplementedException. However, with the PexChooseAsStubFallbackBehavior attribute, the fallback behavior calls into PexChoose to ask Pex for a new string. In this example in particular, on each call to ReadAllText, Pex will generate a new string for the result. You can see this string as a new parameter to the parameterized unit test. Therefore, when we run this test under Pex, we see different behavior happening, including the “hello world” file:

      Note that all the necessary attributes are added at the assembly level by the Pex Wizard.
    • Miscellanous bug fixes and improvements
      • [fixed] Dialogs do not render correctly under high DPI
      • When a generic parameterized unit tests does not have any generic argument instantiations, Pex makes a guess for you.
      • When a test parameter is an interface or an abstract class, Pex now searches the known assemblies for implementations and concrete classes. In particular, that means that Pex will often automatically use the automatically generated Stubs implementations for interfaces or abstract classes.
      • Static parameterized unit tests are supported (if static tests are supported by your test framework)
      • Better solving of decimal and floating point constraints. We will report on the details later.
    • Breaking Changes:
      • The PexFactoryClassAttribute is no longer needed and has been removed. Now, Pex will pick up object factory methods marked with the PexFactoryMethodAttribute from any static class in the test project containing the parameterized unit tests. If the generated tests are stored in a separate project, that project is not searched.
      • The PexStore API has been renamed to PexObserve.
      • Pex supports versions of Code Contracts higher (strictly) than v1.1.20309.13, (which is the currently available version of Code Contracts!).

    v0.9.40114.0, 01/16/2009 (Academic only)

    • Fixing bug in the academic installer that prevented to install on a machine without Visual Studio.
    • Stubs: support generated stubs for non-sealed classes and virtual methods.

    v0.9.40105.0, 01/13/2009

    • Pre-Release License for Visual Studio 2008 Team Dev or Team Test: We have heard your feedback that it was hard to evaluate Pex on the Visual Studio 2010 Virtual Machine. As a result, the Pex research team and the Visual Studio Team Test team have decided to extend the Pex Pre-Release license to Visual Studio 2008 Team Dev or Team Test. Unlike the academic license, the pre-release license does not explicitly prohibit commercial use. Please note that this is a pre-release software with no support guarantees, but the Pex team does its best.

    • Test Framework Integration: Pex already had support for custom test frameworks in the previous version, but it only worked from the command line. We have added support for other test frameworks in Visual Studio as well and you will be able to generate tests for your favorite unit test framework. Similarly to the ASP.NET MVC Test Integration, any test framework can register itself through some registry keys (see extensibility guide (pdf)).

    • Partial Support for Visual Basic.NET and F#: Pex can analyze any MSIL code running on .Net, but it can only emit C# test cases for now. In previous versions, we restricted Pex in Visual Studio to C# projects because the Pex research team does not have the resources to implement and test the infrastructure for all other languages. We have heard your feedback: you can now generate parameterized unit test stubs from the project node of VisualBasic.NET and F# projects.

    VisualBasic.NET also gets code digger, so that you can right-click in VisualBasic.NET files and launch Pex. However, when saving the generated tests, Pex will still generate a C# test project.

    • Better Regression Tests: When Pex tests a method that returns values, it automatically walks the object property graph (recursively) and stores the values as assertions in the code. If you make a breaking code change that can be observed through public APIs, the generated test suite is likely to flag it.

    • StyleCop, FxCop compliance: We have heard your feedback and made improvements to the generated test code so that it is clean with respect to FxCop and StyleCop.

    • Better support for instantiating value types: If a value type can be freely configured through the constructor and public properties, Pex will now automatically do that for you. Thank you for your feedback.

    • Other Features:

      • Code generation for ‘decimal’ type.
      • Ability to solve some constraints over decimal and floating point values.

    v0.8.31021.3, 10/21/2008

    • New Experiences and Major Features
      Code Digger - Code Understanding and Automatic Testing At Your Fingertips; read the announcement and the full Tutorial (PDF)
      Note: The Code Digger experience requires Visual Studio 2008 Professional, or better, with support for the MSTest unit test framework. Otherwise, you will see an "unexpected tool error" in this release.
      Stubs - A Simple Framework For .NET Test Stubs; read the announcement, and the full manual (PDF)
    • Better Reasoning
      New approach to solving constraints involving strings: Technical Report (PDF)
      Better support for reflection (e.g. dataflow tracing to nested reflection calls)
    • New Samples
      File System (PDF)
    • Better Documentation
      More Patterns (PDF) how to write Parameterized Unit Tests.
      Enhanced Cheat Pages (PDF) containing PexAssume and PexAssert.
    • Other New Features
      New button with "clock" icon in main tool strip to make it easy to increase exceeded bounds.
      New "Delete Generated Unit Tests in File" menu item, available in files containing generated unit tests
      Console output of test cases is now shown in separate pane.
    • Bug Fixes, Performance Improvements, Minor Changes, Other Maintenance
      Support for forthcoming .NET FX 4.0
      Suppression of warnings which are hard to understand (they are still shown in diagnostics mode)
      Up to twice as fast Pex experience in Visual Studio on multicore machines
      More robust interaction of the VS AddIn with the Pex exploration process
      Lookup of substitution assemblies is now aware of different assembly versions
      Double click on row in test table selects top-level frame of exception stack trace instead of going to test code
      Fixed memory leaks in constraint solver (Z3)
      Bug fixes around generic types
      Many other bug fixes.
    • Known Issues
      The Microsoft.ExtendedReflection assembly is not listed in the Visual Studio Add Reference... dialog. If you need to reference it, click on Browse and locate the .dll manually.
      When using Pex with VS2010 CTP, note that the Pex samples project is still a VS2008 project. You should explicitly open it from VS2010, instead of double-clicking the solution file in the Windows Explorer.

    v0.7.30916.0, 09/17/2008

    • Lots of Bug Fixes
    • Better Reasoning Capabilities
      Better support for enums, strings, ...
      Integration of "fitness" frontier (in-depth information in technical report, earlier version in source code)
    • Parameterized Test Patterns
      A collection of patterns how to apply and use parameterized unit tests: PDF
    • New Features
      PexExpectedGoalsAttribute, PexGoalException to indicate goals
      DebuggerDisplayAttribute support for rendering values
      New methods in PexAssert: ImpliesIsTrue, Case (documented in Patterns article), AllowThrow
    • Breaking Changes
      PexOracle class renamed to PexChoose
      PexValue class renamed to PexStore
      Microsoft.Pex.Framework.Using.PexUseGenericArgumentAttribute renamed and moved to Microsoft.Pex.Framework.PexGenericArgumentAttribute
      PexMockAttribute removed

    v0.6.30728.0, 07/30/2008

    • 64 bit Support
      Pex can be installed on X64 machine but runs 32-bit processes only (Wow64).
    • UI Changes
      Mostly moving around buttons, changing labels, and adding more icons.
      In particular, the infamous red bar has been integrated into a friendly yellow bar.
    • New features
      Code-update preview dialog.
      New quick actions for generated tests: Debug, Send To... Mail, Text-file, Clipboard.
    • Testability
      Pex flags Testability issues.
    • Fixed bugs and other changes
      Generated code quality: prettier method names, prettier local names.
      Lots of other bug fixes.
    • FatalExecutionEngineError (-2146233082), or StackOverflow (-2147023895)
      This error might occur shortly after you invoke Pex, either from the command-line or Visual Studio. This is a known bug, and caused by a race condition in Pex. Usually, when you simply invoke Pex again, it will work just fine.
    • WPF issue: API restriction: '...WindowsBase.dll' has already loaded from a different location Pex may break your WPF applications. If you experience this issue, please uninstall Pex from the machine. We are working towards a fix for this issue.

    v0.5.30611.1, 06/17/2008

    • First update of Pex!
    • Fixed bugs and other changes
      - Pex now complains gracefully when other profilers are active, e.g. certain mock frameworks.
      - The dynamic coverage view is no longer shown by default in Visual Studio, but it must be enabled (if desired) in the 'Tools' / 'Options' menu.
    • Visual Studio 2005 users
      Visual Studio 2008 Standard (or higher) is required to run the samples and use the Visual Studio Add-in. If you have Visual Studio 2005 or Visual Studio 2008 *Express*, you can still use Pex from the command line. See the tutorial or the command line reference.
    • FatalExecutionEngineError (-2146233082), or StackOverflow (-2147023895)
      This error might occur shortly after you invoke Pex, either from the command-line or Visual Studio. This is a known bug, and caused by a race condition in Pex. Usually, when you simply invoke Pex again, it will work just fine.
    • Pex Wizard in Visual Studio may be slow
      When using the Pex Wizard in Visual Studio, devenv.exe might fully utilize a CPU for a long time. We will work on a fix for this issue in the next release. A workaround is to use the wizard from the command line and using the /testp flag.

    v0.5.30516.0, 05/21/2008

    • First release of Pex!
    • Visual Studio 2005 users
      Visual Studio 2008 Standard (or higher) is required to run the samples and use the Visual Studio Add-in. If you have Visual Studio 2005 or Visual Studio 2008 *Express*, you can still use Pex from the command line. See the tutorial or the command line reference.
    • FatalExecutionEngineError (-2146233082), or StackOverflow (-2147023895)
      This error might occur shortly after you invoke Pex, either from the command-line or Visual Studio. This is a known bug, and caused by a race condition in Pex. Usually, when you simply invoke Pex again, it will work just fine.
    • ClrMonitorFail (-667) This error might be result of an interaction of Pex with another installed Visual Add-in that also acts as a profiler, e.g. certain mock frameworks. This issue will be fixed in the next release. As a workaround, try to uninstall other Add-ins.
    • When the Pex Wizard generates parameterized unit test stubs, it inserts by default a call to Assert.Inconclusive(). This method throws a special exception that tells Pex (and MSTest) that the test is inconclusive.
      This mechanism forces the tester to review and validate each generated parameterized unit test by removing the Assert.Inconclusive() call.
      To suppress generating Assert.Inconclusive() calls in Visual Studio, go to the 'Tools' / 'Options' menu. Then select the 'Pex' / 'Wizard' pane and disable 'Make generated test inconclusive by default'.
    • Pex Wizard in Visual Studio may be slow
      When using the Pex Wizard in Visual Studio, devenv.exe might fully utilize a CPU for a long time. We will work on a fix for this issue in the next release. A workaround is to use the wizard from the command line and using the /testp flag.