My Thoughts on Pex

Earlier this week at work I got an email asking me to install Pex, Microsoft Research's White box Unit Testing framework for .Net.  While my company falling into the "early adopter" category (we're already on .Net 4 and VS2010), this one surprised me since it's a Research project.  I briefly looked into Pex last fall and didn't get too into it since I was content working with NUnit and my current unit testing tools.  Now that it appears that I may be using it to some extent at work, I decided to take a more meaningful look at it.

Like I said previously, Pex is a MS Research project for doing White Box Unit Testing in .Net.  White Box unit testing means that the tests are focused to cover the current code.  This is one of the shining aspects of Pex; it will scan the code to be tested and generate unit tests that cover all logical paths within it.  This is a great way to bring your code coverage up if you aren't getting the coverage rate with your traditional habits.  After Pex scans and tests the code, you can drill into the tests themselves as well as the results.  Pex allows you to update your own code with conditions specific for code under test too.(e.g. Pex can add null argument validation code if you so desire)  When everything is all set with the tests that have ran, you can save them out into a separate or existing project so that they can be ran again later. In addition to all of these things, Pex comes wired up and ready to use an assortment of Unit Testing frameworks beyond MSTest so that it can play nicely with your existing tests and test runners also.

While those elements are awesome and helpful, there are a few things that turn me off of the framework.  Pex will dive into all dependencies found with in the code under test.  Where you traditionally may mock or stub out a dependency, if there's a hard dependency found, Pex will dive into it.  Now, this can be averted using some form of IoC container or Isolation Framework (more on this below); however, if you don't use one of these, that code will be tested as well.  In addition, Pex only tests Publicly exposed code.  If your code is marked as anything other than public, Pex will inform you that it can't test it.  This doesn't bode well for software businesses who have a lot of internal classes.  During my tests, I even tried to use the InternalsVisibleTo assembly attribute and it still wouldn't work with it.  Lastly, I was a bit disappointed in Pex only scans the currently active file inside of the IDE.  While there's a command line way of running Pex, supposedly, from within Visual Studio itself, Pex can only work with 1 file at a time.

Finally, Pex has this nice little buddy called Moles.  Moles is an isolation framework for handling dependencies.  You can use either without Pex; however, they are closely tied together from a project and documentation standpoint (if you find info on Moles, you'll almost always find info on Pex and visa versa).  Moles focuses on generating Stubs in the same way as frameworks like Rhino Mocks and NMock2; however, it also has what it calls Mole objects which focus on Sealed, Static, and or Privately scoped classes.  I did not dive too deep into Moles; however, it would appear that it does not mock these types but rather intercept and detour the method calls into the implementations you wire up. From my understanding this is similar to how TypeMock handles the same task.

Overall, I think Pex is a good product for people trying to get their code coverage up and are in a Test-Last mentality.  It works great under that situation and makes for a great candidate for automating unit test generation of DTO/Domain Model classes that tend to be public due to how they get passed around and usually consist of just getters and setters.  It's not a tool I see myself using personally, though.  I'm human and can see a very difficult argument in justifying a Test-First approach beyond design when Pex can/will write the tests for you.  Applying that logic to a business environment and justifying a few minutes to write some tests to a manager vs a few seconds to run Pex and generate more tests is a hard sell.

Iowa Code Camp: Session Overview

The Iowa Code Camp was held on  November 7th, 2009 in Des Moines, IA.  With a capacity crowd and a lot of great sessions, it ended up being an awesome time with a lot of great presentations and conversations.  Like conference of this type, you never have time to hit all of the sessions you may want to; however, the ones I was able to attend were still awesome.  Below is an overview on each one.

Getting Started With Behavior Driven Development by Lee Brandt

In his presentation, Lee provided a good introduction to the concepts of BDD.  The presentation focused on the origin of BDD, where it fits, and how it's an evolution of TDD from the beginning which helped to truly set the stage.  For those that have done TDD for a bit, it provided a great introduction into bridging the gap between the business case and the code by using tests as a spec.  Through this and Lee's stressing of an Ubiquitous Language as described in various DDD circles, he showed how BDD can be used in order to provide a technique that helps to show the client what the application will do once done as well as a pseudo-burndown chart of what hasn't been finished yet.  I'm definitely looking forward to exploring BDD again in the near future.

Twitter: @LeeBrandt
Blog: http://www.geekswithblogs.net/leesblog/Default.aspx 

Going From 0 to 100 Dollars an Hour with .Net you Didn't Know by Mitchel Sellers

This session was a good session; however, it wasn't as advanced as I was hoping for.  The abstract of the session focused around using advanced features of .net in order to make you more productive; however, I was hoping for some additional tidbits beyond that of the abstract.  The primary items focused on this presentation were new tips and tricks introduced by .Net 3.5 such as Lambdas, Self Containing Properties, and LINQ. All of these items I already knew and have used them in the past which is why I was hoping for a few tidbits beyond such. That being said though it WAS a good session with a lot of good code samples to convey each concept and technology.  I still learned at least one new thing and was reminded about a few other things as well. While it didn't meet my (probably unrealistic) hopes, I cannot deny that Mitchel's presentation definitely educated a number of people who were also in his session that was overfilled.

Twitter: @MitchelSellers
Blog: http://www.MitchelSellers.com 

Open Spaces

I've been to a few open spaces discussion and have came to the conclusion that some will be good, some will be bad, and others will be between or outside of those labels.  The open spaces session at the Iowa Code Camp was an in between session.  The size of the group was smaller and comprised of a diverse set of primary skills which isn't always a bad thing though the topics in discussion didn't flow like I have experienced in other places.  We had a good conversation about how to get the information to the people that don't come to conferences or how to encourage them to come.  We also talked a little bit about MEF, coding war stories, and some of the side effects of completely rewriting/redesigning an externally facing website.  Lastly we talked a little bit about Kanban vs Scrum and the paradox of software estimation.  All in all there was some good things that came up during the conversation; however, part of me was hoping that more people would have been involved in the discussion and the topics would have been more discussion/problem solving based to an extent.

Intro to ASP.Net MVC by Chris Sutton

I've dabbled in ASP.Net MVC and have wanted to learn more about it; however, finding making the time for such is not always easy.  Everything that I've learned about such has either been about the MVC pattern itself, or about other frameworks in general like Rails or Django.  With only a few MVC Videos watched and about 3hrs worth of coding so far, I decided checking out another intro session wouldn't be a bad idea for me.  Chris Sutton did a great job with the presentation.  He explained the MVC pattern very well as well as describing how the ASP.Net MVC framework relates to it and ASP.Net in general.  He showed a couple of the typical demos for this level of session and afterwards answered all of the questions I had about the next step.  All in all it was a very good session and can't wait until I can make time for using such.

Twitter: @ChrisSutton
Blog: http://subjunctive.wordpress.com 

Silverlight for WPF Developers by Kirstin Juhl

In my opinion, none of the last block of sessions really looked appealing to me.  It wasn't the fact that I didn't think any were going to be good, it was just that I wasn't interested in the topics at hand.  I ultimately decided to check out Kirstin's presentation on what WPF Developers would need to know to transition into the Silverlight space.  While I have only dabbled in WPF a little bit, I knew a number of differences and knew the power of XAML was greater in WPF than Silverlight.  The decision to go here was my current adventures in Silverlight and see what I may be able to learn.  All in all, the session was pretty good for the purpose Kirstin was targeting.  She did a good job at explaining the differences as well as provide information on how to share components between Silverlight and WPF applications (something I knew was possible but hadn't seen an example of up to this point).  Good presentation overall.

Twitter: @KirstinJ
Blog: http://www.geekswithblogs.net/Kirstinj/Default.aspx 

Overall:

Overall, I had a great time at the Iowa Code Camp.  For being a free conference, the presentations, facilities, and of course the prizes were all top notch.  It was a great conference with some amazingly talented speakers and attendees.  All in all I can't wait to head to the next one in the April/May/June timeframe.  Hopefully some of the presentations I'm working on will be ready by then since I'd love to present one.

Reviewing UppercuT - A Build Framework Based On NAnt

Earlier this week I went to the Kansas City .Net User Group meeting where the topic of discussion was UppercuT, a build management framework created by Rob Reynolds. The discussion was pretty good and Rob did a good job at showing a number of demonstrations on how to use the various aspects of UppercuT. All in all, I feel like the presentation got the point across as to the typical why/when/how/etc. questions.

What Is UppercuT?

UppercuT is a build management framework based on NAnt. It was created in order to establish a consistent way to build .Net applications with a minimum amount of configuration while providing areas for extensibility. In addition to just compiling, UppercuT provides a number of options to manage application versioning, automated testing, and code packaging. While it can be extended to include such steps through NAnt, UppercuT doesn't deploy code...it only stages it since every company/project's deployment strategies may be different. One nice thing that UppercuT does do in terms of deployments though is provide you instructions on how to wire it up to CruiseControl.net.

When Should UppercuT Be Used?

UppercuT provides a way for people who have not started to take advantage of automated builds to do so quickly. Because of this, it's best suited for projects that don't have automated build systems integrated into them yet. With some configuration changes, it is possible to integrate with your current scripts; however, changes would need to be made on both side to the point where it would honestly be easier to convert your current scripts to custom steps for UppercuT to take advantage on. If you currently use some build framework like MSBuild or NAnt, I would probably recommend at least checking out UppercuT to see if it's a good fit; however, if you or your company already have some system that works for you in place, it may be better to just keep with what you have.

Where Can I Download and Learn More?

You can find more information on Uppercut by going to it's project website at http://ProjectUppercuT.org. In addition, you can check out Rob's blog over at http://ferventcoder.com/ as well as on Twitter by following @ferventcoder and @ProjectUppercuT.