Geeks With Blogs

@onefloridacoder

News
John Smith's Blog Keeping the fun machine running one nickel at a time

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:

image

 

 

 

 

 

 

 

 

image

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.

image

image

 

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.

 

imageFurther 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.

image

 

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.

image

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.

 

image

 

 

 

 

 

 

 

 

 

 

 

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.

Posted on Tuesday, May 26, 2009 9:50 AM | Back to top


Comments on this post: Flex Your Pex (Part 4)

# re: Flex Your Pex (Part 4)
Requesting Gravatar...
Unique plein cadran onyx noir avec de grandes mains, l'échelle de temps de fluorescence, même si au fond plongée dans l'obscurité encore clairement maintenant. Ultime "poisson volant" édition limitée Breitling Chronographe, sans montre chanel peur du noir, avec un sentiment profond braver le charme ultime.Presque toutes les marques de table masculins jouent les signes "de reproduction classiques?. Que ce soit la copie Atlanta série Jeux olympiques, ou de première génération édition de la copie limitée, ou tout simplement un style classique inchangé 100 années ont remporté la faveur des hommes.Série J12 est né en 2000, inspiré par l'océan. replique montre Chanel trésor, une série de montres de luxe nous a apporté son lot de surprises. Ses élégantes et le déplacement de l'état, tant de gens sont fascinés. A indiqué que la montre de Chanel, de nombreuses personnes première pensée est de J12.
Left by Belle on Jun 28, 2013 3:40 PM

# re: Flex Your Pex (Part 4)
Requesting Gravatar...
Great post, keep write the best content :)<br>Readmore
Left by rachmadp24 on Jan 13, 2014 4:31 PM

Your comment:
 (will show your gravatar)
 


Copyright © onefloridacoder | Powered by: GeeksWithBlogs.net | Join free