TDD Anti-Patterns

I Like this.  Have seen most of them (and probably been guilty of a few a while ago…)


I suggested a couple of others…


How about the ‘Stealth Bomber’. This is probably an extreme extension of the Hidden Dependency. I’ve seen a few tests that would simply ‘never’ fail when run interactively or debugged, or during a full test run in the day. When a supposed ‘fix’ was implemented it would even fool the developer into feeling pleased with themselves by passing for a day or two before bombing again in an overnight run. The logic wouldn’t show anything untoward, and it continued to bomb every few days without warning or trace of ‘why’. More than likely a group of no-no’s of execution sequence-dependent, date/time-dependent, database-dependent, context-dependent etc.


There’s probably another variation – maybe the ‘Blue Moon’. A test that’s specifically dependent on the current date, and fails as a result of things like public holidays, leap years, weekends, 5 week months etc. This is again most likely guilty of not setting up its own data.

Enable any user to increment Performance Counters

I thought I was being a bit clever some time back when I wrote a little .NET wrapper for performance counters, largely for the reason of allowing clients to happily work with counters that weren’t installed on their machine.  The default behaviour is an exception when you attempt to use a non-existant counter.


This was all good until deployment to servers and clients with ‘real’ non-admin users.  I then read that only administrators and power users could increment counters (awww!).


I just found this MS article that explains how to get around this as the ‘permissions’ are simply based on registry permissions for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib.


To set the permissions,



  1. Open Regedit to that key
  2. Right-click, select ‘Permissions…’
  3. Add your user’s groups or specific name with ‘Full Control’

I can now actually implement the solution (1 year on!)