There and Back Again : Test Driven Development

Last Old Blog Code Update

hdierking — Fri, 07 Mar 2008 10:12:00 GMT

Ok - after posting this update, I'll consider myself caught up with regard to picking up the pieces of my old blog. This is the updated code sample for creating custom mapping types in NHibernate. The updated sample provides a loose example of implementing the type object pattern - a pattern where one object instance serves as the type for a set of other object instances. Here, for the sake of simplicity and expediency, I have designed the types such that the type object is also the value container - hopefully when you look at the code, you can see it's a pretty simple process to go a step farther and implement the full pattern.

Anyway, similar to my last post, I've updated the code to use the latest version of NHibernate, and I've added in some LINQ goodness. And of course, all demoware disclaimers apply.

Old TDD Demo Blog - Digest and Code

hdierking — Sun, 02 Mar 2008 10:24:00 GMT

Several of you have emailed me over the past several months asking if I had a copy of the blog text and/or code that I had mentioned in a much earlier blog entry. As it turns out, a good friend of mine found some old archived versions of the site on an Internet cache and set them over to me. Therefore, I have taken the web pages and compiled them into an XPS document so that you can see the thought progression that went along with building a small application, TDD style.

Additionally, I've updated the code samples a bit. Specifically, I've upgraded the version of NHibernate to 1.2.1.GA - and as such, dropped the use of Ayende's NHibernate Generics library. Also, as I was going through my NHibernate mappings, I realized that I had been pretty lazy with regard to semantic accuracy for collection types - I had pretty much completely used <bag> mappings instead <set> mappings for unordered collections so that I could use IList<T>. Therefore, I cleaned that up a bit. Other than that, the only other thing that I did was update some of the looping and conditional code to use LINQ.

Finally, let me emphatically throw out the "Demoware Disclaimer" - The point of the blog and the code samples was to illustrate the thought process and corresponding code behind using TDD to design a domain model. As a result, everything else in the code is the simplest thing that could be implemented to support the overall goal - and nothing more.

Wow - That Was Annoying

hdierking — Mon, 19 Nov 2007 05:18:53 GMT

So I'm in an awkward place right now when it comes to programming. In addition to the fact that I no longer program on a day-to-day basis (which is starting to bug me a little more than it used to as I'm afraid I'm starting to atrophy a bit), I'm also now up on Visual Studio 2008 - which is really great in a lot of respects - but at the same time is kind of bumming me out. I'm not bummed because of anything inherent in Visual Studio - I'm bummed because Resharper just doesn't really work all that great in it. Don't get me wrong - R# works - but the semantic analysis tools don't yet work with a lot of the C# 3.0 language enhancements - and as much as I tried to ignore the R# compiler errors on things like Linq queries, I finally just got tired of it an uninstalled R#, impatiently awaiting the 4.0 release.

Firstly, let me just say that not having R# is miserable from a refactoring standpoint.

Secondly, losing R# led me down the path to another headache (which is the subject of this post) - I no longer have a VS add-in runner for NUnit. Yes, I know - I could (and probably should) go back and download TD.NET - but instead, I was curious to see how easily it would be for me to just convert my NUnit tests to VS 2008 unit tests. In short, it's not terribly difficult, but getting there was a frustrating journey.

Why? Because unlike NUnit, where a test fixture is explicit in code (and only in code) via the TestFixture attribute, VS tests rely on a second piece of metadata in order to have them run via the VS test manager/test runner. That metadata is not found in the *.vsmdi file - instead, it's actually a property in the project file of your unit test project.

Therefore, if you started from a regular class library project and need to have it recognized by VS as a "test project", open the *.csproj file in notepad and add the following to any PropertyGroup.

The first Guid identifies your project as a test project (the second is the language I believe - feel free to correct me if I'm wrong).

Linq-i-fying My Existing Projects - Part 1

hdierking — Wed, 14 Nov 2007 19:09:39 GMT

To be honest, I don't know how many parts there will end up being - since the longer I'm away from day to day developing, the fewer projects I have to go back through. However, I can think of a few more off the top of my head - so I still think that "Part n" is a fair statement.

Anyway, for a sample golfing application, I have the following hierarchy (fragment).

Now, ignoring for the moment the fact that I didn't make Round a generic and thereby avoid the need for it, the following method in Round validates that either Players or Teams can play a round of golf, but not a mixture of both (e.g. - a single player cannot go up against a team).

private void ValidatePlayerTypeConsistency(Player[] players) {

foreach (Player player in players) {

if (!player.GetType().Equals(_expectedPlayerType))

throw new ArgumentException("Player was not of the expected type ('" +

_expectedPlayerType.FullName + "')");

}

Using a C# 3.0 Linq query, the imperative structure of the foreach loop can now be replaced with a more declarative one as follows.

private void ValidatePlayerTypeConsistency(Player[] players) {

bool hasUnexpectedPlayers = (from p in players select p)

.Any(p => !p.GetType().Equals(_expectedPlayerType));

if(hasUnexpectedPlayers)

throw new ArgumentException("Player was not of the expected type ('" +

_expectedPlayerType.FullName + "')");

}

A couple of quick things to notice here:

In the Linq query, the C# 3.0 language extensions do not cover the entire breadth of Linq functionality (e.g. - the "Any" quantifier). When you run into cases like this, remember that it is perfectly acceptable to mix the language extensions syntax with the standard extension method/lambda syntax. You can do this by simply enclosing the language extensions syntax block in parentheses and then calling additional methods on the result.
My Linq query syntax didn't really reduce my total line count and the declarative syntax is arguably harder to read. To this, I can only say a) this is a really simple example and b) like anonymous delegates and generics, you get used to it. That said, this example should illustrate that you should take a pragmatic approach to incorporating new features like Linq into your applications.

A final note here - I am ONLY able to do this type of code replacement because I have a great set of unit tests backing me up. In fact, when I first tried out the Linq approach, my test failed. DO NOT make changes like this to working applications without having good tests to back you up.

Hopefully, I'll bring you some more complex examples soon.

ALT.NET - Trip Report

hdierking — Fri, 19 Oct 2007 06:41:58 GMT

I had the recent opportunity to travel to Austin, TX to attend a meeting of the minds of those who are considered thought leaders in the .NET agile/open source space. This community, in somewhat of an expression of feeling that the general .NET community (as guided by Microsoft) has gone in a different philosophical direction with regard to designing and building software, has aptly elected the name ALT.NET. While the meaning of "ALT" was the subject of several spirited debates, my general takeaway is that "ALT" is simply shorthand for "alternatives". The plural is important here because this community is not defining themselves or their values as the alternative to Microsoft technology and guidance. Rather, at the core, they are more interested in trying to promote the development of leaner, more maintainable software using whatever tools are most helpful to those ends (Microsoft or otherwise). To give you an idea of just how big this community's toolbox is, see the following.

Frankly, I think that the choice of the "ALT" moniker, while not meant to be seen as an alternative to Microsoft (which would actually be contradicted by the ".NET" part), is born out of the general frustration by the community that the tools Microsoft gives developers enables short term productivity and long term headaches - while at the same time decreasing the overall skill of developers and making them dependent on a specific type of tool (e.g. - designers).

The conference was conducted in a format called "Open Space". In this style, there were no formal sessions and no formal presenters. Anybody who wanted to talk about (not necessarily lead) any subject could put it forward to the group and schedule it for a time slot/meeting room. As such, Simon Guest and I sponsored a talk on how to engage the ALT.NET community with the rest of the .NET developer community. From those individuals who attended the session, we were able to identify a few interesting points of feedback.

The community feels that MSDN and MSDN Magazine are stale and sterile, and that while there are lots of "how-to" articles, there is very little content that explains "why".
There was a general lack of awareness about newer offerings from MSDN online - particularly the architecture dev center.
Many of the audience are already avid and well-followed bloggers, and as such were skeptical as to the value-proposition of writing for MSDN Magazine.

As to the first 2 points, I think that there is a lot we can do as an organization to incorporate many of the ideas expressed at the ALT.NET conference - for MSDN Magazine, the first obvious step is to get more people from this community to write for the magazine - which leads me to the third bullet. The point that I kept reiterating to the participants was that while things like blogging and holding ALT.NET conferences are great, they're an echo chamber. People who visit ALT.NET blogs are generally going there because they have already bought into at least some of the philosophy. If you want to really affect change in the larger community, you need go to the community - and MSDN/MSDN Magazine are 2 fantastic ways to go about it. I think that this message resonated well, as, since returning, I have received several article submissions from conference participants.

In sum, this is a community that really wants to see people develop better software, and it was very encouraging to see Microsoft recognizing their contribution to the community by way of the number of Redmond folks in attendance. Going forward, it will be exciting to see both how this community evolves - and how their values and practices have an impact on the larger development community.

If you want to know more about the conference, such as the specific sessions/topics, I covered each day of the conference on my blog - so see the following.

Click here for pictures from the conference.

Scrum Room?

hdierking — Wed, 11 Apr 2007 08:56:06 GMT

If you're going to do any job, you may as well have some fun with it. Great work Bil!

Microsoft Acquires TeamPlain – Free to TFS Customers!

hdierking — Tue, 27 Mar 2007 21:18:12 GMT

This is a really awesome deal for current Microsoft Team Foundation Server customers. Check out the entry on Rob Caron's blog for more information.

Team System Unit Tests and Deployment Items

hdierking — Sun, 25 Feb 2007 02:24:57 GMT

Just a quick tip in case you haven't yet encountered this yet. In the course of my development rhythm, I use both Visual Studio Team Edition for Software Testers and TestDriven.Net as test harnesses for my unit tests. This is primarily due to speed. As I'm sure you're aware, the VSTE test engine takes a good bit longer to initialize than TD.NET and because my programming style is very TDD in nature, I like to run my tests more frequently, and from the test code itself. Now, I ran into a situation today where I wanted to do some testing on an Xml schema that I wrote. Therefore, I have the following test.

   1:  [WorkItem(93), TestMethod]

   2:  public void testGetAssetTypeSchema() {

   3:      XmlSchema assetTypeSchema =

   4:        ((IXmlSerializable) new AssetType("temp")).GetSchema();

5:

   6:      XmlReaderSettings xmlSettings = new XmlReaderSettings();

   7:      xmlSettings.CloseInput = true;

   8:      xmlSettings.IgnoreComments = true;

   9:      xmlSettings.IgnoreWhitespace = true;

  10:      xmlSettings.Schemas.Add(assetTypeSchema);

  11:      xmlSettings.ValidationFlags =

  12:        XmlSchemaValidationFlags.ProcessIdentityConstraints;

  13:      xmlSettings.ValidationType = ValidationType.Schema;

  14:      xmlSettings.ValidationEventHandler +=

  15:        new ValidationEventHandler(settings_ValidationEventHandler);

16:

  17:      XmlReader xrdr = XmlReader.Create("Workstation.xml", xmlSettings);

  18:      XmlDocument xdoc = new XmlDocument();

  19:      xdoc.Load(xrdr);

  20:  }

My "Workstation.xml" file sits in the project directory along with everything all of the rest of my code files. I run my test using TD.NET and I get a file IO exception – my Xml file could not be located. Oh – woops! I forgot to change the "Copy to Output Directory" property. This ensures that when I build my project, the Xml file will always get copied into the output directory along with my assemblies. To do this, I select my Xml file in the solution explorer, and look at the properties window. I can then find the "Copy to Output Directory" setting and change it to "Copy always".

Now, at this point, my test will run just fine with TD.NET because that test harness runs my tests "in place". However, VSTE creates an entirely different folder structure to manage test runs and test results. Therefore, when I run my test with VSTE, my test fails again. To correct the problem, I need to add one more attribute.

[WorkItem(93), DeploymentItem("Workstation.xml"), TestMethod] 
public void testGetAssetTypeSchema() { ... }

The "DeploymentItemAttribute" will cause the VSTE test engine to copy my Xml file from the assembly output folder to the test deployment folder – and therefore the relative path I specify in my test still works flawlessly.