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.