Share this page
Pex - Release Notes

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.