Sunday, September 30, 2007

Test Data Builder versus Object Mother

When writing unit tests, I frequently have an issue with creating objects that contain some test data. One approach is to call the constructor of the class at hand in every test case, like so:

[Test] public void TestCase1() { Customer customer = new Customer("Homer", "Simpson"); // further implementation } [Test] public void TestCase2() { Customer customer = new Customer(null, "Simpson"); // further implementation } [Test] public void TestCase3() { Customer customer = new Customer("Homer", null); // further implementation }

The problem with this approach becomes clear when adding a new argument to the constructor of the Customer class. Now I have to make a change to all tests that create a Customer object.

What I did to overcome this issue, was to use the Object Mother pattern. I created a static class called TestFactory with a bunch of constant fields and methods that create all kinds of objects: 

internal static class TestFactory { public const String FirstName = "Homer"; public const String LastName = "Simpson"; private static Customer CreateCustomer(String firstName, String lastName) { return new Customer(firstName, lastName); } public static Customer CreateValidCustomer() { return CreateCustomer(FirstName, LastName); } public static Customer CreateCustomerWithoutFirstName() { return CreateCustomer(null, LastName); } public static Customer CreateCustomerWithoutLastName() { return CreateCustomer(FirstName, null); } }

I didn't really like this approach. For every special case, I needed to add another factory method. I couldn't come up with something better either at the time, so ... until I read this fine article yesterday. Instead of using the Object Mother pattern, the author uses the Builder pattern.

public class CustomerBuilder { public String _firstName = "Homer"; public String _lastName = "Simpson"; public CustomerBuilder WithFirstName(String firstName) { _firstName = firstName; return this; } public CustomerBuilder WithLastName(String lastName) { _lastName = lastName; return this; } public Customer Build() { return new Customer(_firstName, _lastName); } }

The tests itself would look like this:

[Test] public void TestCase1() { Customer customer = new CustomerBuilder().Build(); // further implementation } [Test] public void TestCase2() { Customer customer = new CustomerBuilder() .WithFirstName(null) .Build(); // further implementation } [Test] public void TestCase3() { Customer customer = new CustomerBuilder() .WithLastName(null) .Build(); // further implementation }

Looks pretty neat huh? If you're interested in writing maintainable unit tests, then you should definitely give the article a good read. The examples are written in Java, so I don't know if that has got anything to do with it :-).

Saturday, September 29, 2007

Article on Dependency Injection

Mark Monster has written an excellent article on Dependency Injection in the newest .NET Magazine (it's no MSDN magazine, but hey, its free of charge). Nonetheless, there are two things I want to mention here.

The author says that Loose coupling is mostly used in the context of SOA and web services. I don't agree. I won't deny the fact that this is also important for SOA, I think that Loose coupling comes from Object-oriented programming. A minor detail perhaps, but hey, you know me. I'm just being picky.

The second issue is when he mentions that it's absolutely necessary to have a Dependency Injection container when using Dependency Injection. This made my alarm bells go off. I completely agree when we are talking about medium-sized to larger projects here. But, I consider it to be harmful when used in smaller projects. How do you know when to use it then? As soon as you experience difficulties when not using a DI container.

Personally, I'm using Dependency Injection for a long time now, and I only have had a few projects where I really wanted to use a DI container to make my life a little easier. I believe YAGNI is an important thing in software development. I recently did an investigation on wich DI container we should use in case we need it. Turns out that Castle Windsor is very powerful and very easy to get started (its also used in the article). I didn't consider StructureMap or Spring.NET, but I guess they are equivalent to Castle Windsor.

Wrapping up this post, I want to say kudos to Mark for putting up an article on Dependency Injection. I consider this an important topic (used with or without TDD), and there are not enough developers out there who use this in there day-to-day coding efforts.

Rubiverse Podcast

I just finished listening to the first two episodes of the Rubiverse Podcast. The first episode is an interview with my personal Microsoft hero of the year John Lam. I really enjoyed the second episode with Scott Bellware. Scott is an MVP for some time now and a true .NET alpha-geek who is making a shift to Ruby and Ruby on Rails. Martin Fowler and Scott Hanselman already wrote about this here and here. If he is right, then this would make Richard Grimes the Nostradamus of the .NET community ;-).

The next quote from Scott made laugh out loud:

How much office furniture will Steve Balmer smash when Ruby on Rails goes up in IIS in a Microsoft produced language?


The Microsoft produced language would then be IronRuby of course. I've got some high hopes on IronRuby. At the moment I believe that Microsoft, John Lam and this team will give us a great IronRuby implementation that makes it possible to run Ruby on Rails applications in a Microsoft environment. This is probably some weird naive thinking on my behalf, but hey, give the inner child in me a break. Would Microsoft allow this scenario to happen? Is IronRuby going be a weak implementation whose sole purpose is to serve Silverlight, in wich case it's the next big disappointment? Or is it going to become a first class citizen? As mentioned by Scott in the podcast: it's all in the hands of John Lam.

I'm still a believer at the moment. I'll keep you posted.

Monday, September 24, 2007

Bug Driven Development

Are you doing Test-Driven Development or Bug Driven Development? From my experiences, test-driven development seems to slow you down at the beginning of a project. This isn't entirely true, it just feels that way. When you can overcome this and keep hanging on, the benefits become apparent when going towards the end of the project. You have only a few bugs to solve (if any), and everything seems to fit perfectly. No more debugging sessions that seem to take forever, no more working long hours and you are confident to make changes based on the feedback of your customers just because you have a ton of unit tests to back you up.  How is that for an argument?

Tuesday, September 18, 2007


Does this put good old Borland CodeGear back on the map? Anyway, I'll definitely have a look at the trial version.

Monday, September 10, 2007

Duck Typing

Great posts from Phil Haack on Duck Typing:

Really awesome stuff!

A day of great quotes

Scott Bellware:

I think that the difference between a good developer and an excellent developer is the excellent developer's willingness to not know, an openness to explore, and faith in skills that guide solutions to good ends even when the end is not known at the outset.

Read the entire post

Oren Ellenbogen:

Agile is a constant thinking about how we, AS A TEAM, can produce working features to our users with high quality within a short time-frame.

Read the entire post

Sunday, September 02, 2007

Improving Applications Design with a Rich Domain Model

This is the title of an awesome talk that Chris Richardson gave at the Spring One 2007 conference in Antwerp. You can watch this session online. He gives a really nice introduction to domain-driven design and also discusses some code smells and their corresponding refactoring solutions along the way. Although the used programming language is Java, the content is applicable to multiple programming languages and environments including .NET.

I believe that we have a huge lack of these kinds of sessions in the .NET world (except for the ALT.NET conference). The content of this talk is essential for every developer, analyst, project manager, etc. ... out there. So, what are you still doing here reading my crap? Go watch this stuff!

Saturday, September 01, 2007

Community efforts

I'm with Scott on this one. The fact that Microsoft duplicates the efforts of their own community is simply inexcusable. Why does this bother me? Using the best tool or library to do the job is al it takes, right? Wrong! The problem starts with companies (including the one where I work for) that use the crappy Microsoft alternatives in favor of their open-source counterparts. Why? Simply because it has a Microsoft label on it. And this kind of decision making starts to piss me off.

Take NUnit for example. I'm using it for a couple of years now without a single complaint. Recently I've got a lot of questions why I'm not using Team System Unit Test. It sucks too much right now (you can read my comparison over here). Roy Osherove mentioned on his blog this week that the upcoming Team System Unit Test capabilities may finally be "OK". It's about time, don't you think? They finally managed to get the basic features of a unit test framework implemented. Great! But it doesn't change a thing. If someone wants me to convert all my unit tests to another unit test framework then it better be worth it. And frankly, at the moment it's not, not even the with new features in Visual Studio "Orcas". Switching to something like MbUnit is much more like it.

Unit test frameworks is just one thing. So, how long before Microsoft releases a mock object framework? Place your bets ...

My Simpson Character

Give it a try at Simpsonize Me.