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.