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.

Two things: I'm thick; and one cannot use a Mockbox mocked method as a callback

G'day:
And to think someone said on Twitter the other day that I'm one of those people who are never wrong (the subtext being "actually you are, but just will never admit it"). Well here's an example of me being wrong, happily admitting it, and admitting to being a bit stupid to boot.

Weird issue with MockBox and interfaces: issue identified

G'day:
A coupla days back I wrote a vague article "Weird issue with Mockbox and interfaces", which detailed some weirdness I was seeing with using Mockbox to mock methods in CFCs which implement an interface.  The short version is that on the first use of a method mocked this way, I was getting this error:

coldfusion.runtime.InterfaceRuntimeExceptions$ArgumentsMistmatchException: Function argument mismatch.[etc]

However if one just re-ran the test, the problem went away. In fact it was only the first usage of the mocked method after ColdFusion was started that caused the problem. Subsequent runs: all good. Restart CF: problem. This is on ColdFusion 9 & 10, but not Railo.

Weird issue with Mockbox and interfaces

G'day:
This is not gonna be a very well-realised article, as it's posing a question that I've not really been able to flesh out yet.

Repro case for "contains" pseudo-reserved-word interfering with Mockbox

G'day:
This is mostly for Brad Wood, but it might be of passable interest to others, so I'll plonk it here.

Yesterday's article discussed how contains is kind of a reserved word, but kind of not in ColdFusion (it's just not in Railo). I observed to Brad that this actually bites us on the bum with Mockbox, and he asked for more info, so here it is.

Basically we use a caching system which has a method "contains" which checks to see if there's an item with a given key already in the cache, before trying to fetch it. We've actually since revised this approach, but we have some legacy code still using methods called "contains". So we need to unit test them, and indeed their responses play a part in other methods we test. When testing these other methods which use the caching system, we mock-out the cache, and the methods within it, and we use Mockbox to do this. Mockbox is cool, btw. You should be using it if yer not already.

We're still using Mockbox 1.3 (more about why further down), and it is impossible to directly mock a method called contains using Mockbox. We've worked around this, but it took a bloody long time to work out what the hell was going on, and that there was working-around to do.