Challenging Conventions with Test First Development

I've just read a great post over at Tim Ottinger's blog.  In it he discusses how test first development challenges conventional development.  He makes several interesting points, some of which include:

Point 3: Private makes less sense than it used to. You can’t test anything that’s private.

This is something I often ponder over.  Making things private makes your intent very clear, which I think is very important.  But private implementation is still a unit of code that needs testing.  Then again, as described in Test Driven Development: A Practical Guide,  unit tests should test the facets of behavior.  As Dave Astels puts it in this blog post:

"... the idea of “unit” is a major problem. First of all it’s a vague term, and second it implies a structural division of the code (i.e. people think that they have to test methods or classes). We shouldn’t be thinking about units… we should be thinking about facets of behaviour."

To me, the term 'facets of behaviour' reads that 'behaviour' has 'facets', and that private implementation makes up each facet.  So by testing the facets of behaviour, you are really testing units of private implementation (i.e. private methods).  This point may be worthy of a new post...

Point 4:  The fat constructor argument list is a concession to the need for isolation and testing with mocks...

Good comment.  I always refactor any code I see with a fat parameter list so it takes a 'property bag' instead.  In ReSharper, this refactoring is called 'ExtractClassFromParameters'.  The benefit of this is cleaner, more separate code, and also overcomes C#'s limitation of not having default parameters (i.e. you leave it null/default in the property bag).

Point 7:  Hard to use class interfaces are now hard for you to use...

Exactly.  Which is why I find TDD a great way to figure out 'how to design an API/Framework' rather than 'how to implement the API/Framework to achieve something'.  Something that made a lot of sense when reading the Framework Design Guidelines is to forget OO when designing the public interface to an API - i.e. design it so it's easy to use for the most common scenario.  Exactly what is achieved by practicing TDD.

Handy .NET Cheat Sheets

John Sheehan has some great cheat sheets on string formatting, ASP.NET Page Lifecycle and Visual Studio code snippets.  Very handy.  I'm sure there's a medical explanation as to why it's impossible to remember string formatting parameters for more than 1 minute after you've discovered them!

Getting 'code://' hyperlinks into FlexWiki

Reflector, when installed, adds a "code://" protocol handler, enabling hyperlinks to specified types in assemblies.  This handler is similar to http:// or ftp://, but instead of taking you to a web site, it takes you to a type in an assembly!

For example, code://System.Web/System.Web.UI.WebControls.WebControl will launch Reflector and navigate to the WebControl type in the System.Web.UI.WebControls namespace.

Custom types can also be navigated to, although the associated assembly must be loaded first.

By default, FlexWiki does not handle all protocol handlers. To get it to handle the code:// protocol, a recompile is needed.  I'm working with version 2.0.0.41. Later versions are now available, but the code should be in a similar place.  So, for version 2.0.0.41, changes are needed to the file:  FlexWikiCore-2.0.0.41-src\EngineSource\Formatter.cs.

Change lines 1706 and 1707 - adding the 'code|' segment next to the https?| text:

static string urlPattern = 
  @"((https?|code|ftp|gopher..." ) ;

static string urlPatternInBrackets = 
  @"((https?|code|ftp|gopher..." ) ;

I must say, it's very handy for your team to be able to navigate directly to code from a Wiki entry.