I have finished a couple of books that I would like to plug here. One is “The Art of Unit Testing” and the other is Regular Expressions Cookbook. I waited for both to drop, and as soon as they did I picked them up.
The Art of Unit Testing
The Art of Unit Testing (TAoUT) has received many awesome reviews with some folks guessing there may be a *DD book coming out soon by the same author. Well see, and it would be nice to have a compilation of *DD guidance for those that can dig(g) and use a *DD form.
TAoUT demonstrated a lot of common sense maneuvers and choices in how to construct, use, and maintain your unit tests. There really is more to it than meets the eyes especially after you get your eyes in front of this book. If you’re familiar to UTs it might be a quick read, maybe not. I thought I was a great tester, but Roy schooled me on a few things that make a lot of sense to me now.
This isn’t chicken soup for your unit testing, but it’s a way to learn how to step back and say, hmmm, I think I’ll write them differently. If you’re read my blog before you know I like PEX, very much. But at times PEX may be a very large answer to a very small problem. This is about using the right tool for the right job, and in this case it’s my brain that I need to use, along with Roy’s guidance. This is the way to get it, then pass it on to the next *DD’er that walks into my cube.
I would highly recommend you pick up this book and see how it can benefit you, your (non)existing UTs, and/or your test team. I was looking at testing code a lot differently the week after I finished this book, hopefully it will do the same for you.
Regular Expression Cookbook
I wrote many lines of weird and cryptic Unix shell code to strip, extract, glue, paste, and count text out of flat files in a previous life. A few years ago I was writing a lot ASP code and thought at times “ A RegEx would just be the sweetest (and more maintainable) thing to do for this problem “. Especially since we picked validator controls that could evaluate a RegEx.
When I saw this book come through my RSS reader one day, I was thinking about what I wrote above. I know very little about writing or building a RegEx, but I’m really excited to know that this book will help me figure this out and drop another tool in the toolbox. In other O’Reilly books the “mascot” on the cover is usually explained maybe this has changed but it looks like Templeton, the rat from Charlottes’ Web, this fact is interesting on a few levels.
The book has already gotten some awesome reviews on Amazon and they are correct in their assessments. I’m recommending this book as well. I have a Safari account so I could read the book without any restriction but I purchased it anyway. There’s also a Kindle edition if that’s how you like your reading material presented.
More later.
My Pex has not flexed recently. Peli has dropped a new version of Pex with a few breaking changes and I’m two revs behind him on implementing. One thing that I’ve come to realize is that I can’t manage the churn taking place for the code under test. The last few sprints have introduce large amounts of change in our persistence model and that, well, just screws the pooch when you’re trying to keep things updated. I’m trying to figure out the best way to manage the churn in my testing libraries – and hopefully Peli implemented some of my hidden feature requests he noticed a while back.
In addition to this a framework for Silverlight UI testing dropped (twice) during my last sprint and this was an interesting and valuable distraction from Pex. However, in Pex’ defense, it is very easy to rebuild anything you’ve constructed so far but my advice would be to version your custom code. I built up many stubs and factories for Pex to use when it needed to build up certain types. Most of that code I can keep since the interface changes were limited in some areas. Other areas it was not, and that code will just get dropped.
My strategy will probably revolve around the UI and service implementations and balance when they are getting close to “done-done”. Most of the Pex setup work can be done on the “not-so-done” elements and then will get fleshed out when they arrive at “mostly-done-done” stage. We have a mocking library as well which has a lot of code that will change as well, but for the most part isn’t adding much value while Pex is duplicating some of this effort. The library we are using works with Pex, so I may have the libraries join forces and/or just build my own PUTs for the “mostly-done-done”, this would be on the service implementations.
That still leaves the Silverlight unit testing work, it’s very automated as well and can using the A-A-A model for building tests like Pex suggests. Oh, and the bread crumbs I need to leave behind for the sustainment folks as well have to be straightforward otherwise I’ll be building tests that won’t be used in the future for regression. Pex helps with this, but folks will need to (want to) understand how that happens. All of this to aid in getting us closer to CI – more rapid feedback for all to see and use.
More later.
Last night I finished my first SketchFlow project last night. I was using the (free) first chapter of an upcoming book “Dynamic Prototyping with SketchFlow in Expression Blend”. This copy doesn’t look like first draft stuff, it’s stuff that you can use right now. The free chapter gets you grounded with how you can put SketchFlow to work for you.
The first thing I did was set aside what little I knew about prototyping. I’ve used many napkins to layout an app and that makes total sense. The examples do as much but have added color to their napkins (sketches). While building this first project I wanted to make things click and move, add behaviors, “oh, I can make this spin or flip!”, you get it. Resist that urge and wait to satisfy those “demons” when your layout is finished.
Taken from the “Who Should Read This Book" section
If you’re a software architect or developer that often finds yourself thrust into playing the role of a designer in your projects and day to day activities you’ll find that the techniques put forth here will enhance your ability to do better work. This book shouldn’t however be regarded as a replacement for having the capability and skill of a professional designer on your project team.
Bingo. I won’t feel too guilty about wearing a designer hat for my own projects, but my designs shouldn’t go much further than something that has a Balsamiq look (which it can do OTB), nothing polished but still conveying intent. That’s what we’re after right? Not even being a devigner (or Deselepor as they said on C9 yesterday) myself, it was hard not to stay out of the behavior folder. But I did. If you’re the hard core designer, you probably have more business in that behavior folder than I but get the layout right and flowing first. Let me rephrase that, get your sketches laid out and flowing, first. Adding navigation is a snap and once I wired the navigation for each object in the SketchFlow Map surface (the pane on the bottom with the colored shapes) it worked. After I started exercising the the flow navigation when I ran the app a few things happened: more/better ideas for the flow and layout started appearing; I dropped a shape and added two; made a few navigation connection swaps on a few shapes which made more sense after walking through the app; I came up with a better name for some shapes. Two words: rapid feedback. Two more words: love it.
I followed along in the first chapter until the author begin importing assets. Then I scanned my own sketches I had done a few nights before during a trip to the library with my kids. Within an hour I had things snapped together and the SketchFlow Navigator was moving me around the layout. The export to Word worked as advertised. I’m going to take this back to see if I can enlist some folks using Blend for the first time to help build up the application. This will mainly be an exercise to help move myself and someone else forward using this technology. I’ve already added the few initial user stories to my AgileZen backlog so I ready to go.
Lessons Learned
- Scan as grayscale if using #2 pencil and regular 8x11 paper
- Ink pens or Sharpies work better but don’t have erasers
- Can add some color for emphasis using Sharpies
- Multiple sketches on one page can be imported as Sketch01, Sketch02, …
- Multiple sketches on one page, then use Paint(.net) to crop into individual sketches
- Import cropped sketches, images, etc. into appropriately named folders with descriptive names
- Cropped sketches with real names that match SketchFlow shapes helps with Assets display later on.
- If possible use generic names for sketch components so they can be composed on multiple shapes
- Try to keep Sharpie tips off of the library table tops
BDUF was especially interesting when I heard Peter Provost and Billy Hollis speak on this topic during their presentations at the PnP Summit last year. Both made points that I could definitely relate to. You see the (embarrassing) thing about this post is that I didn’t know what BDUF was, and was living it everyday, but waterfall was supposed to be OK? I never heard anyone say BDUF until I hooked up with .NET a few years ago (I wrote my first line in December of 2003), even having done a few tours with Java (1.1) and VB6/ASP. Instead it was a place I had spent many years living in, remember The Truman Show, like that.
I was driving home today after a very long day of WCF unit testing for a current project I’m helping with and realized why the day was so long. I wanted everything to work like it was a BDUF project. I thought everything I was working against in the DAL was done, that’s what you finish first, right? A very awesome coder who is our technical leader is cranking out some awesome NHibernate bits for our DAL. But we’re using Agile to make this solution happen. My first sprint planning meeting I was biting my tongue to keep from asking BDUF questions, this was the first sign that this BDUF was very deeply engrained in this developer’s habits and thoughts. Maybe I’m making it sound worse than it is. But having done so much BDUF development which never really had a great design to begin always looked like something else, and didn’t really hit the target, budget, or timeline. I’ll stop there, I won’t throw anyone under the bus – teams succeed and fail together.
I thought it was worth throwing out a few words on the topic since I’m really enjoying the Agile development and the community is by and large running with it (slowly) as well. But, to a point that Billy Hollis made, waterfall development has a place in some shops projects. He gave an example on building rule-based systems where the rules needed to be defined before the system construction could start. And in that example, his team was successful and the customer was happy with the result.
However, in my experiences, I’ve seen and been a part of the teams that left a wake of poorly written code that couldn’t be maintained. How could this happen? I think that some folks believe that it’s far less expensive to support a system than to (re)build it. I heard Michael Feathers discussing a Strangler System on Hanselminutes. I can see this approach working for some of those systems, however the date on the article is June 2004. Just like Truman I was fast asleep and no one was trying to wake me up back then. If the community was thinking about Strangler Systems, we were probably aware that the waterfall might not be a great thing.
This sprint is going very well so far and it’s still early. The customers are asking great questions, providing awesome feedback during the cooldowns – and we are not reacting, but we are responding. And my part of the sprint will be going even better once I get back to my desk and comment out the code that really shouldn’t have been written in the first place. Refactoring code that doesn’t even serve a need yet, geez! But with BDUF you are always in that 9th inning push to clean the bases and bring everything home. Like Ted Williams, I’ll just try to get my three hits each game, win or lose. Someday I’ll get to Fiji, the airfare in my part of the division is getting cheaper by the sprint.
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.
// <copyright file="CreamyLayerManagerTest.AddBread.g.cs" company="Microsoft">Copyright © Microsoft 2009</copyright>
// <auto-generated>
// This file contains automatically generated unit tests.
// Do NOT modify this file manually.
//
// When Pex is invoked again,
// it might remove or update any previously generated unit tests.
//
// If the contents of this file becomes outdated, e.g. if it does not
// compile anymore, you may delete this file and invoke Pex again.
// </auto-generated>
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.
// <copyright file="CreamyLayerManagerFactory.cs" company="Microsoft">Copyright © Microsoft 2009</copyright>
using System;
using Microsoft.Pex.Framework;
using PeanutButter.Business.Facade.Creamy;
using PeanutButter.Business.Entities.Enums;
namespace PeanutButter.Business.Facade.Creamy
{
public static partial class CreamyLayerManagerFactory
{
[PexFactoryMethod(typeof(CreamyLayerManager))]
public static CreamyLayerManager Create(Bread bread_i)
{
CreamyLayerManager creamyLayerManager = new CreamyLayerManager();
creamyLayerManager.AddBread(bread_i);
return creamyLayerManager;
// TODO: Edit factory method of CreamyLayerManager
// 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.
public class CrunchyLayerManager : IBusinessLayerManager
{
public Sandwich Sandwich { get; private set; }
public CrunchyLayerManager(Sandwich sandwich)
{
ConfigureSandwich(sandwich);
}
private CrunchyLayerManager()
{
}
private void 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.
We’ll start here next time. Until then.
I’ve refactored part of the project and removed the generic methods, and added in a few new public methods to illustrate building a real sandwich.
To keep the example a bit realistic, I’m leaving the Crunchy layer in a rougher state and building up the Creamy layer. I’m not a big fan of crunchy peanut butter sandwiches, but in a pinch it will do. Pressing on.
Our solution looks like this now.
I’ve asked Pex to go back through the solution and hook up PUTs for me. One notable thing to mention here about rerunning Pex Explorations. During my refactoring I broke the contract between the facade manager PUTs that Pex had already created. And Pex said, “So what!” So the solution would not build, because of this, but the facade library would build – your code needs to build. Pex will try to regenerate what it needs on its own during the Exploration process.
In some cases there was code that I could have corrected (namespaces, etc.) and in some cases I did, but in some cases I dropped the test project and stepped back through the previous steps we’ve covered to rebuild the PUT project.
In the project I was first testing Pex with, I did this a few times and it was not a big deal, especially since I had my PUTs versioned in a source control system.
Here’s what the Pex Explorer looks like now, the Crunchy layer methods are throwing NotImplemented exceptions right now. We’ll deal with those as well but not right now.
The Pex Explorer has a different view of things now as well. The ctor for the CreamyLayerManager is the “target”, and Bread.Wheat (an enum) is being passed in to the manager’s AddBread method. The “Details” text box is displaying the AddBread01 test method and how the target is being created and the methods being called on it.
This dialog shows us a few other things as well. Beneath the test method details we have a “Save Test…” button which corresponds to the icon in the far left grid’s gutter. That icon means we have a new test, that needs to be saved. And yes, you’ll get used to that.
Additionally, we have a visual prompt for “1 Object Creation”.
Pex wants to help us stub out a factory to create this particular layer manager. When we click the Accept (if it’s new) / Edit (if it’s not) button Pex will prompt to tell us it’s about to alter our PUT project, like this. Very cool – no surprises, right!? Clicking “Apply”.
Pex Exploration Results change to tell us (visually) something good has happened, and the Factory has been added and we should be looking at it in our code editor, which we are. This is the type of behavior that Pex is delivering, so you don’t get lost and can follow what’s going on.
At this point, I’m going to add all of the other factories Pex may have suggested as well as the other test methods that need to be saved.
Remember the methods that were throwing exceptions, well those come into play now as well.
A few things to note with this exploration, the test is still passing in a “wheat” argument like the other method that’s not throwing, but Pex has picked up on the fact that it is throwing something intentionally. The test still needs to be saved, and the exception still needs to be allowed.
In a better scenario, when may have a guard condition on an argument when it’s passed in. If it was null, we could throw if it ways. In this scenario Pex would setup a test that allows for this scenario to happen and would build up a PUT with a null argument so we can get coverage on that part of the code block. On a live project, you might have these laying around, and it’s perfectly fine.
Clicking “Allow Exception” looks like this.
The tests that are expecting to throw are just like all other tests that throw. The point is just to make Pex aware so when I come back to flesh out these types, the PUTs will change based on my changes, but because of Pex’ interaction.
My test runner (xUnit) is telling us the same stuff Pex told us. These will stay in the red stage until we’re ready make them green.
Before I close on this one, I wanted remind everyone again that I did have to regenerate my PUT project a couple of times over the course of setting up the PUT project and refactoring my code since this is a new Pex build. This probably won’t happen now that most of the groundwork is laid, and we’ll work more with Pex, and less with the source code.
Until then.
After cleaning up the “Not Implemented Exception” throws in the concrete class implementations of IBusiness Manager, Pex delivered a set of PUTs for each layer.
Here’s the details in the Pex Exploration window. Notice the disk in the lower right hand of the icon in the far left gutter, we have a new test. Each new test will have that, telling us we need to save it. If it’s an update to the PUT, then we’ll just have the sunburst in the upper left hand corner. The other visual queue is under the “Details” rich text box… “Save Test…” Clicking “Save Test…” generates a new dialog that tells us what Pex is about to do to our PUT project.
Pex is *very* good about telling us what he’s going to do to our projects and PUTs, so this type of dialog is going to get very familiar, unless you tick the “Do not show this dialog in the future” checkbox. I would let it pop until you get used to Pex and you’ve moved through at least one set of your examples to see what Pex can do, and is doing, for your PUTs. After we click “Apply” we get a summary of each successful or unsuccessful step.
Now, were have a test method that was previewed in the dialog above. Notice the green check mark icon as well. This test is part of the Pex test project now. Well do the same for the rest of the new tests, individually.
The unit test explorer looks like this now:
Our unit test base line looks like this:
We have some very boring code. We need to pass in something to Add, Remove, and Update so we can see some of the other Pex features, and how Pex’ behavior changes based on your code structure. That’s next.
Until then.
Pex has had two updates, one since I first used it, and one after I finished using it. Here’s the release notes for the latest build that dropped on 5/1/2009. Fresh install, and rewinding back through the project I had referenced in my first post. This time I need to build a different project that doesn’t reference my day job and also how well things work with xUnit.
The install was perfect again, no issues with that so far. Here are the
release notes, and a few steps setting up a new project. I’m just going to start a new project and start from scratch and buzz through the same examples I worked through previously. Here’s the new project setup.
Now that I’ve got a new project to work against, we can generate the Pex test project and ask Pex to get busy. First we’ll ask Pex to create a new xUnit test project. Right-clicking the Facade project exposes the context menu, we’ll choose “Create Parameterized Unit Test Stubs”, aka PUTs.
This gives us the following dialogs to set our project properties. I’ll leave the blanks blank, those exist to filter the namespace, type name, and method names you want to filter for the project under test. We want all of them, so they’ll be left blank.
A variation on this is if you open the context menu inside the class file. The filter fields are filled in for you to limit Pex’ interaction.
Here are the settings I’ve chosen, I’m going with xUnit this time around.
The “Settings…” dialog is where I tell Pex that for all unit tests created, each will have the PexTest suffix.
"Mark all test results Inconclusive by default" - This setting will add the Assert.Inconclusive() assertion at the bottom of the test method which is the default for all Visual Studio unit tests when they are generated in the IDE.
"Globally qualify all types" - This setting will prefix all fields in the test class with global qualifier.
"Use Code Patterns" - Pex utilizes many different code patterns which are beyond the scope of this document. You can find them in this document's appendix.
"Generate Stubs file for project under test" - The Stubs Framework utilized by Pex is explained by one of the authors here.
We click OK on the settings dialog. We click OK on the main dialog, and Pex shows us the dialog pictured below. We’re getting a unit test project called …\ProjectName.Tests (plural suffix); now is your only chance to move this project around. If you like to keep your unit test libraries somewhere else besides the project it’s testing move it to that place. The MSTest dialog gives us a singular suffix. So if you have both, this might help you keep them apart. Hopefully they will allow us to (re)label them in future versions of Pex.
Click OK.
If Pex can’t find your test runner, you’ll be prompted for the location.
Here are the new pieces Pex has added.
A few things to notice here. We get one Pex class for each of our classes so the test methods are segregated neatly. The point to make here is to get everything neat before you generate the test project. Also, notice the suffix, "PexTest". We can't rename the class library suffix, so I chose to rename the class files so I know by looking at the project members which classes are mine, and which ones were generated by Pex. Also, the stub file mentioned previously is generated for us.
Here’s what Reflector can show us about what was created as well, the crunchy layer looks pretty much identical to the Crunchy layer.
namespace PeanutButter.Business.Facade.Creamy
{
/// <summary>This class contains parameterized unit tests for CreamyLayerManager</summary>
[PexClass(typeof(CreamyLayerManager))]
[PexAllowedExceptionFromTypeUnderTest(typeof(InvalidOperationException))]
[PexAllowedExceptionFromTypeUnderTest(typeof(ArgumentException), AcceptExceptionSubtypes = true)]
public partial class CreamyLayerManagerPexTest
{
/// <summary>Test stub for Add(!!0)</summary>
[PexGenericArguments(typeof(int))]
[PexMethod]
public void Add<T>([PexAssumeUnderTest]CreamyLayerManager target, T entityToAdd)
{
// TODO: add assertions to method CreamyLayerManagerPexTest.Add(CreamyLayerManager, !!0)
target.Add<T>(entityToAdd);
}
/// <summary>Test stub for Remove(!!0)</summary>
[PexGenericArguments(typeof(int))]
[PexMethod]
public void Remove<T>(
[PexAssumeUnderTest]CreamyLayerManager target,
T entityToRemove
)
{
// TODO: add assertions to method CreamyLayerManagerPexTest.Remove(CreamyLayerManager, !!0)
target.Remove<T>(entityToRemove);
}
/// <summary>Test stub for Update(!!0)</summary>
[PexGenericArguments(typeof(int))]
[PexMethod]
public void Update<T>(
[PexAssumeUnderTest]CreamyLayerManager target,
T entityToUpdate
)
{
// TODO: add assertions to method CreamyLayerManagerPexTest.Update(CreamyLayerManager, !!0)
target.Update<T>(entityToUpdate);
}
}
The only Source Analysis violation are related to moving the using statements inside the namespace declaration and the adding the method arguments to the summary block. Source and Code Analysis compliance was one of the latest features added to the Pex release in use.
Notice the method decoration "[PexMethod]" This method won't be visible to the xUnit test outline since unit tests are reference by the FactAttribute. If it would have been decorated with "[Fact]" it would. Also notice Pex methods are parameterized (PUTs) tests. The xUnit methods will be generated from, and by, the PUTs.
The PexMethod(s) will be used during the Pex Exploration we will step through now. Right-clicking the test project exposes the Pex Exploration menu item which starts the exploration process.
Pex Exploration finishes and the Pex Explorer tells us we have some problems - all of my methods are throwing NotImplementedExceptions” - nice. 
I’ll stop here, fix my code and pick-up with an Exploration exercise to allow Pex to do something meaningful with my test project.
Until then.
Discussing the use of Pex to build your unit tests through unit test discovery.