Skip to main content

Test Driven Development (TDD) ... a few thoughts ...

I completed a project a few months ago using TDD (got motivated to give it a go following the architecture camp). The system is in production, and is by all accounts performing well. So yes, pleased with the results. It is difficult however for me to know whether I would have been able to acheive the same results if I had not done TDD - if I were to guess ... I think the result would have been solid either way. The system is non UI, back-end process, so all of the complexities associated with accommodating a UI system (WinForms or ASP.NET, Page/From lifecycle, blah, blah, etc) were removed.
The learning curve was certainly frustrating - I think in during steepest part of the learning curve I sent a post to the DNUG entitled 'TDD-ious?' as a result of my frustration :-/ The DNUG however was certainly a valuable resource during this time, and once it was recommended to me - and I started using Resharper and TestDriven.NET - the penny dropped. Actually, I think that doing TDD without using a tool like Resharper is equivalent to doing .NET development using Notepad (i.e. without VS) - it's really painful and just not worth it when these tools exist.
So, my approach was to implement the Dependency Injection pattern, TestDriven.NET and NUnit for testing, etc, NMock for object mocking (Rhino Mocks is probably more popular), and Resharper for everything in between. All of this makes VS feel a little top heavy, and you want to get ontop of your configuration and settings fairly quickly. I think the significant (i.e. frustrating) part of the learning curve was over by the time the work was about 50% complete (by "about 50% complete", I mean "of the total number of hours that went into the project, half of them were gone" - i.e. not "about 50% of the code had been written"), from there I had the DI pattern sorted, had come to grips with Resharper, and was able to implement a test then develop the implied code fiarly efficiently. I still felt a bit clunkly with TDD once I had closed the project, but feel competent enough with it to say that I understand how it works. I estimate that across the course of the project, 20-odd percent of my time could be attributable to 'learning TDD'. I think that this 20-odd percent would have become less and less if I had continued with TDD.
Summary - if/when you get a suitable opportunity to give TDD a go, then I recommend you go for it - you have nothing to lose and everything to gain by trying it. You may even be fortunate enough to see the light (I think I caught a glimpse of it ;-)! I think TDD is a useful approach to know how to use, whether you pursue it long-term or not. Also, the TDD following seems to be growing right now, so if you're going to be in the software development business for a while, at some stage you're almost certainly going to encounter a situation that requires an understanding of it.
Personally, I'm not using TDD right now - I have no excuses ;-)


Popular posts from this blog

HOW-TO: Add/edit a field in Team Foundation Server 2012 using Visual Studio 2012

It's been a while since I made a purely technical post...

So, today I wanted to make a change to a Microsoft Team Foundation Server 2012 (TFS2012) instance that I am working with to reflect "Actual" time spent on a task - mainly for reporting purposes, and because I have found in the past that making this minor process adjustment yields a relatively useful metric over the long-term.

I am using the Microsoft Scrum 2.1 Process Template ( for a project that I am working with. So that I don't forget how to do this (again!) I will blog-post the procedure I've used to add this field to the template as a screen-shot-based tutorial, as follows...
Before Assuming you are familiar with the Scrum Process Template (2.1-ish) - open a task and take a look at the "Details" section, as follows:

 This is where I want my "Actual" field to show up.
Get the Power Tools Download and install the latest v…

HOW-TO: Apply a “baseless merge” in Team Foundation Server 2010 (and 2012)

Another purely technical post on TFS...
The scenario We wish to migrate code between branches that do not have a branch/merge relationship, in order to expedite urgent changes being made by a project team, without disrupting on-going BAU development work. Sample branch hierachy/strategy Imagine the following branching strategy in TFS (visible by connecting to TFS via Visual Studio 2010 or 2012):

Essentially you have a "DEV" branch, which has a "QA" branch, which in turn has a "PROD" branch. DEV is the branch that you would be using for BAU development. As a piece of development matures, you move it into QA, where it is tested by your internal QA team. There may be further changes made in DEV that are moved into the QA branch as the QA team pick up issues. Once the QA team are happy with a packaged of changes, they will move them into PROD, which is essentially the hand-over to the customer. The PROD branch represents the software that the customer has.


Eclipse/Android error: "Multiple dex files define [...]"

Wow, I am really going nuts blogging this-evening - 2nd post in less than an hour. 

Anyway this is a particularly nasty error that I keep running into with Eclipse/Android when starting the emulator after I have not run it for a little while. Since I run the risk of permanently forgetting the solution to the problem every time I walk away from my Android project (and thus having to spend a painful hour-or-so digging up the procedure again), I will blog it here, for my benefit, and for the benefit of anyone who may also suffer the same problem.

The gist is that when you start the emulator in debug mode (that is, you hit the button in the following image), you get the following error message come out on the console and a nasty popup telling you nothing more than there is an error with your program and you need to fix it:

[2012-04-06 23:20:57 - Dex Loader] Unable to execute dex: Multiple dex files define Lcom/google/gson/ExclusionStrategy;
[2012-04-06 23:20:57 - SimpleList] Conversion to Dal…