Unit Testing / TDD - getting stuck on how / what to test (part 1/2)

G'day:
Today I'm gonna go over some head-scratching (some of which is still bugging me) I did on the weekend. I kinda got stuck with how I should be testing something, and this raised questions as to whether I even should be testing something. It's a reasonable exercise to go through, so I will document it here. First: recap.

This is an ongoing series of articles about unit testing and TDD (and will diversify from there as I progress), with - so far - five previous entries:

• Unit Testing / TDD - initial rhetoric
• Unit Testing / TDD - why you shouldn't bother
• Unit Testing / TDD - MXUnit and test scenario
• Unit Testing / TDD - why you should bother 
• Unit Testing / TDD - more tests, more development  

Unit Testing / TDD - more tests, more development

G'day:
So enough prattling about <cfclient> for the time being (and, no, I haven't finished with that topic, but Adobe have demonstrated themselves up to the task of ridiculing themselves without my help at the moment, so I'm just leaving them to it). Back to something more useful: TDD / unit testing.

So far I've written four articles in this series:

• Unit Testing / TDD - initial rhetoric
• Unit Testing / TDD - why you shouldn't bother
• Unit Testing / TDD - MXUnit and test scenario
• Unit Testing / TDD - why you should bother  

Only the third of which had any code in it: the rest was just general discussion. Today I'm going to continue developing this createEventObject() idea I've had, using TDD.

Unit Testing / TDD - why you should bother

G'day:
OK, I actually showed some code in the last entry in this series, but now we're back to me spouting rhetoric (read: waffling on). This stems from Andrew Scott making a very good observation about a benefit of unit testing (not so much TDD) in a comment in my last article:

Adam, can I add another under estimated use for TDD. Apart from the bit you touched on about refactoring. But there comes a point when one will need to migrate to a newer version of ColdFusion or Railo, and this would help identify migration problems as well.

And Andrew is dead right.

Unit Testing / TDD - MXUnit and test scenario

G'day:
OK, so I've prattled on a coupla times about TDD and unit testing from a theoretical point of view:

• Unit Testing / TDD - initial rhetoric
• Unit Testing / TDD - why you shouldn't bother

I think today I'll actually get around to writing some code.

This assignment I'm setting myself could all end in tears, as I'm really putting my money where my mouth is... not only am I going to take a straight TDD approach to writing these tests, I'm also actually doing the design of the function I'm testing as I go too. I have just an idea of how something might be able to work, but I don't actually know if it will be viable yet: I've gone over it in my head, but I've not written any code yet. Other than the test rig.

Similar to my code deferral function from a coupla weeks ago ("Threads, callbacks, closure and a pub"), which handles calling blocks of code in an asnyc fashion, running callbacks at various milestones in execution, I started to wonder if I could write an event-driven system in a single function too. Only a proof-of-concept sort of thing, and most as an exercise in leveraging closure in a real world way (most closure examples I've seen don't actually leverage closure, so I'm all for examples that do), and just to see if the thought exercise can pan out into real code.

My theory is I should be able to have a function which returns a coupla other functions which handle event triggering (trigger()) and listening (on()), and because they'll implement closure, they'll remember the main function's variable context, so will both be able to communicate with an central event registry.

Unit Testing / TDD - why you shouldn't bother

G'day:
Here's the second in my intended series covering unit testing and TDD and anything else that springs to mind. Earlier in the week I started the series intended to get straight into code, but my intended "intro paragraph" ended up being an entire article, which was then retitled "Unit Testing - initial rhetoric".

So I'm not looking at code today, instead I'm gonna look at why you oughtn't bother doing unit tests.

Huh? Yeah, that's an odd thing to suggest in a series about unit tests, innit? Well let me be abundantly clear now that I'm below the fold, and you're reading the article and not just reading the intro: there are no bloody reasons why you shouldn't unit test. And you're a muppet if you think there are. I should add that I'm not having a go at people who thusfar haven't been doing unit testing etc for whatever reason, but those people generally know they should have been doing it, but haven't for [some reason which they probably concede is invalid]. I'm only having a go at people who try to justify their position as being a valid one.

Unit Testing / TDD - initial rhetoric

G'day:
I was talking to a mate/colleague the other day @ CFCamp, and the topic of unit tests came around, and that they... well... didn't do any. They were aware this was not good, but had a sorta mental block of how to get going with TDD and the whole idea of test-first code-second. I had to admit I only started doing unit testing in my current role, and I have our lead architect, Simon Baynes to thank for this. For the preceding decade or so of my development career my approach to testing was the standard cowboy approach of if something didn't seem to break it was probably OK. A lot of people take this approach. It's a shit approach. Don't do it.

In my own defence (it's a lame defence, I hasten to add), I can explain away my lack of unit testing practice for the first few years of my career as I was one of these typical CFML developers who wasn't aware of the wider industry around me, so having not thought to investigate stuff like good coding practices and to check how other people did stuff. Also when new to dev I was in a very jack-the-lad cowboy-ish environment in which doing a decent job of anything was shunned in favour of doing the quickest job possible. Not ideal.

However ignorance is not a defence, and certainly for a few years after my start I was well aware of unit testing as a concept, but never really looked into it. I was like "yeah, I know I should look at this stuff, but it'll just end up meaning I have to write a whole lot of boring test code, and who wants to do that?" This is a very immature, lacking-in-self-disciple attitude, which I now regret.