The DaxMindMapper Reloaded

I know it’s geeky, I know everyone but me has seen it before .. but I still think it’s hilarious:

.. or at least they can be if used straight out of the can within your code and leaving no programmatic means by which you can override them.

Example

You have a .NET assembly running under an app domain, within that assembly you have an object and on the object a method you wish to test. This method’s behaviour is effected by the app domain’s config file within which the object is running. So .. if you run this from within NUnit the behaviour is effected by the NUnit config file.

Question: How do you test the _other_ behaviours of that method when you can only choose one config setup within the NUnit’s config file? What happens if there’s ten, twenty,.. different combinations and permutations of the method’s behaviour depending on that config file?

Answer: You can’t. Not without changing* the system under test (SUT) .. ideally refactoring the method/object so that you can somehow lose the dependency on the config file so that you can control the behaviour of the method programmatically and therefore automate the testing.

*OK, OK I suppose you could attempt to automatically host the SUT in numerous app domains with all of the config combinations setup .. all generated on the fly! Can’t believe that doing this won’t be slow and, kinda missing the whole point that there are already perfectly acceptable (and understood) patterns to solve this kind of testing issue: interfaces + dependency injection + mocking.

Interactive debugging using VS is great .. up to a point. However as soon as the solution grows to even a moderate size then the whole experience begins to turn sour. The solution is slow to load (god, it’s soo slow) and even slower to debug.

I reckon you know your going to having problems when your UI layer has references to more than ten other projects (no one heard of the facade pattern for gawds sake).

But anyway .. seems to me that better unit testing (via TDD or for whatever off reasons you may do it) means that you spend less time in the debugger becuase it’s one whole type of bug you’ve just gotten rid of. That’s got to be a good thing from a monster solution point of view.

Important point to note re: Refactoring (well it is to me anyway). Refactoring is changing the implementation of your code but not what it functionaly performs i.e. the how is being changed not the what.

However refactoring is also something which is relatively quick and, with the right tools in place, probably something which could almost be automated. It’s also something which is not a high risk venture or something which takes a long time. Anything which is complex, risky and/or takes more than an hour is probably a code re-write .. I think Fowler call’s it a re-organisation of your code or similar.

So don’t fool yourself .. refactoring should be pretty easy, pretty painless and something which doesn’t take your code through the some very suspect states inbetween check ins. If this is what your doing then please bear with Agile development .. what your going through is not the way it should be and is most likely a function of hurried code.

http://xunitpatterns.com/ - the next book to get I reckon.

“It has been said before but it bears repeating: writing defect-free software is exceedingly difficult. Proof of correctness of real systems is still well beyond our abilities and specification of behavior is equally challenging. Predicting future needs is a hit or miss affair (we’d all be getting rich on the stock market instead of building software systems if we were any good at it!)

Automated verification of software behavior is one of the biggest advances in development methods in the last couple of decades. It is a very developer-friendly practice that has huge benefits in productivity, quality and keeping software from becoming brittle. The very fact that so many developers are now doing it of their own free will speaks for its effectiveness. ”

Once I’ve been through it I’ll write up a review.