# Wednesday, September 30, 2009

Phil Haack recently wrote a blog post about a tricky use of Moq where one needs to set expectations for successive method calls. Here’s the specification of the problem shamelessly copied from his blog post:


So we want to set up a mock to return 0 or more ‘true’ and a final false. With Moq and the help of an extension method, Phil managed to express this in a single line of C#.


Let’s do it with Stubs!

Stubs is a stub framework solely based on delegates. In that sense, it does not provide any helper to express a sequence of calls so we need to do that in C#. An easy approach is to create an array and use a counter to iterate through it (sounds familiar right?). This is exactly that this snippet does:


SIDataReader is the code generated stub type of IDataReader. It has a field Read of type Func<bool> that can used to stub the Read() method.

Putting Pex into the mix

Why did we have to specify the values in the test? We should let Pex decide the sequence of booleans that are relevant to test code. To do so, we refactor values as a parameter and add an assumption to ensure that the last element is false.



posted on Wednesday, September 30, 2009 10:36:55 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [2]
# Wednesday, September 16, 2009

We just released v0.16.40915.5 of Pex. The major highlights of this release are Moles, a lightweight detour framework, and better support for test frameworks.

  • 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.(sample outdated) 
    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.
    • And many other bugs that were reported through the forums.
posted on Wednesday, September 16, 2009 2:16:33 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]
# Wednesday, September 09, 2009

Since it’s been almost a year that we’ve released Pex, we have started a little survey on our forums. We are looking for feedback on how you use Pex and how you would like to use it. If you are interested, please voice yourself  on our mini survey at


The questions are:

1. Are you using Pex already? A) From Visual Studio, B) the command-line, C) other, D) no
2. Which version of Visual Studio are you using? A) Professional, B) Team System, C) other
3. How many people are in your team?
4. Do you write A) Parameterized Unit Tests (PUTs), or B) only use the Wizard-generated PUT stubs?

Any other comments are appreciated as well, about the license terms, or required Visual Studio versions…
Thanks,  The Pex Team

posted on Wednesday, September 09, 2009 3:47:42 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]
# Sunday, September 06, 2009

While on parental leave, I could sneak a couple hours to read a paper on Frontier Search by Korf and al. Frontier search is a kind of best-first search algorithm that reduces the needs for memory. A very interesting and relaxing read… I add an implementation to QuickGraph that follows the idea.

posted on Sunday, September 06, 2009 10:17:05 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]
# Friday, September 04, 2009

The new release of Code Contracts is out and brings a very cool feature: Xml comment generation. This means that you do not have to worry about keeping the comments in sync with the code, the compiler takes care of this.

Contracts to Xml Comments in action

Unless you invest a lot of work in them, Xml comments are most often worthless. For example, in QuickGraph, the documentation of the Edge constructor is really… well… useless (oops my fault):


However, the body of the constructor contains Contracts that state the pre-conditions and post-conditions of the constructor: source and target should not be null, etc… With the new xml comment generation, these contracts will be added to the xml documentation and ultimately will show up in the compiled documentation.

First, let’s turn xml comment generation on in the property pages:


Once the project is rebuilt, we can take a look at the generated xml documentation file. The ‘requires’ and ‘ensures’ elements are now under the Edge constructor element:


Finally, we run the documentation file through Sandcastle*** to get the final result (make sure you update the Sandcastle stylesheets that come with Contracts. Read section 8 of the documentation):


Voila! With this feature, you have a documentation that never goes out of date.

posted on Friday, September 04, 2009 8:57:23 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [5]