A couple of notes about my environment that I didn’t state before. The laptop I’m use is a typical laptop 4Gb of memory standard dual-core, with 64-bit Vista Ultimate as the OS. There don’t appear to be any limitations Pex in on 64-bit, but there are a few messages you’ll see on the dashboard that state that Pex Explorations are going through some kind of “(x86) cold-start”. The first time saw this I thought that I might need to spin up a test project on a 32-bit VM, but it works fine on a 64-bit box. It was built for Vista 32/64-bit machines and should work but are untested on XP, and versions of Windows Server. Here’s the requirements from the Pex site:

There are two builds for Pex, found here. The academic and the not-ready-for-primetime commercial pre-release versions. I’m using the one noted to the left. I used a previous version on a recent project, and I’ll bump it up to this build, or the next build if the Pex team drops one sooner. The only extra piece in play is xUnit, which is what I’m using for unit testing at the moment. Pressing on.

Running the test runner right now, you’ll notice some tests have a strike-through effect. The unit test explorer is telling us that it can’t find the AddBread01 and AddFlavoring01 unit tests, among others. We do have AddBread02 and AddFlavoring02 though. Why? Some of the unit tests are dropped from the test project when a Pex Exploration is called to run (by you). Refreshing the test session shows the correct state of our test project.

If your test projects are being versioned, you’ll see quite a few checkouts when you are working with the Pex test projects. If you are on team where devs are building their own tests as they build up their code, they probably won’t have a problem creating new , or updating existing, test projects separately. Our shop will probably take the approach to build a separate Pex project for each logical or physical layer or project. At this time, we’ll probably just focus on the non-visual layers. And work out any kinks with multiple devs working in and around the same layers. The lower layers may remain static, while the higher layers may shift a bit during later iterations or refactoring exercises.

If you’ve worked with Silverlight you’re familiar with classes the come in pairs: {Classname}.g.cs and {ClassName}.cs. The “g” denotes a generated file, and Pex generates PUTs for us, so they are also included in our project as well. And as such, the Pex author graciously tells us if we muck around with the generated (g.cs) file we are wasting our time. Much like the EntLib source code and unit tests I read a while back, there’s some interested things that show up in them from time to time, so reading is cool. Just don’t waste your time trying to tweak them.

// This method should be able to configure the object in all possible ways.

// Add as many parameters as needed,

// and assign their values to each field by using the API.

}

}

}

Here’s the factory that Pex wanted us to create. The job of this object is to spit out a CreamLayerManager when asked – it’s a factory and that’s what they do.

Notice the file header, not a .g.cs so we have a full and creative license to work inside this file without any worries of having it regenerated. One thing to note here. If your factory spits out something that’s not quite right, you’ll have to figure that out. Pex will begin to act a bit funny if it’s expecting a shoe object and you give it a skateboard object. It’s your responsibility to ensure that the factory is providing the correct objects that are configured properly.

Further down in the factory class (from above) we see a message from the author that let’s us know that we need to sort out this object.

The TODO also states that the object needs to be configured in all possible ways. So if you’re building a shoe object, make sure it has has shoe laces if it calls for them. The managers in the exercise are pretty boring. The don’t have any internal state to manage, but some manager objects may. There could be public members that need to be setup before Pex asks the object to do any work.

Right now Pex isn’t finding anything else that needs to be done. Our CreamyLayer manager is coded and covered; our CrunchyLayer is throwing NotImplemented. And all of our tests are green. If you think back, our LayerManagers implement IBusinessLayer and we didn’t get a factory for the Crunchy Layer. We’ll see if we can make that happen.

I’ve changed the CrunchyLayer implementation and see what affect that has. Most notable is that the default constructor is private and the (public) overloaded version must be doing something different. The constructor is calling a private method to configure the Sandwich object. I’m basically hard-coding a very large sandwich with a lot of peanut butter.

publicclass CrunchyLayerManager : IBusinessLayerManager

{

public Sandwich Sandwich { get; private set; }

public CrunchyLayerManager(Sandwich sandwich)

{

ConfigureSandwich(sandwich);

}

private CrunchyLayerManager()

{

}

privatevoid ConfigureSandwich(Sandwich sandwich)

{

sandwich.Slices = 4;

sandwich.Toasted = true;

sandwich.Layers = 4;

sandwich.Topping = Topping.MorePeanutButter;

sandwich.BreadSlices = 4;

this.Sandwich = sandwich;

}

// ...

}

Let’s see what Pex has to say about the changes.

We’ll first of all the “g.cs” generated files are expecting a public constructor with no arguments, not the one I supplied.

So at this point, it’s safe to say that if we regenerated, the CreamyLayer manager test won’t change, but the CrunchyLayer tests will. Re-running Pex Explorations without fixing the build. Pex will run against the broken build.

And it does. We have some tests that are passing, but some failed tests have shown up. We can use the Pex Explorer Results window at the bottom of the IDE to see what happened.