Not sure? Write a test

November 5 2008

today i was pair programming with a developer (in my no-more-so-extended mentoring activity). i joined her desk while she was fighting with a complex test (reflection stuff) on a huge object mapper (about 200 fields). i already told her some days ago that, maybe, there could be a way to split it.. nevemind, today the issue was with the test.

first thing i suggested was trying to find which part of the test was wrong, so we started “refactoring” the test moving one piece in a separate helper class and test it in isolation. [i said “refactoring” because there was no green bar when we started. it was like working with legacy code, which you wuold like to refactor, having no test at all.]

i know, maybe it sounds strange to test the test (as the Latin said, “Quis custodiet ipsos custodes?”), but i found many times it’s a good way to get feedback on what’s going on, expecially when you’re “developing” a base test class, instead of extracting it from existing test code.

so, we had a green bar on a simpler scenario: mapping a custom object (a two fields DummyObject class written just beside the test) with the super-magic-reflectionist helper class. then we put some complex field into the dummy and added assertions to the test. bingo! a red bar on the screen, telling us that, probably, we found a way to reproduce in a smaller scenario what was the failing cause.

dilemma: was the tested code bad or the test itself poorly written? i had no idea (i was very very tired, but pleased of someone asking for my help), neither she. when i’m completely lost, i need some feedback, in order to say “ok, this piece works, that doesn’t”. so i asked my mate “are the test data correct? do you think this Map contains a value for X?”. as she said “obviously no!”, i exclaimed “well, let’s write a test!”

what a surprise when we had a failure on assertFalse(mappedValue.containsKey(".."))!

it was now clear: the test was wrong. what we then did is not so interesting (basically, write a simpler and correct test and have it pass, then move back to the original scenario). the focus in this story is on using the tests as a way to gather feedback, whatever you’re doing: coding, testing or spiking.

many developers don’t see the value in testing as a feedback tool. they prefer to code and debug. in my opinion, debug is a powerful but exhausting techinque, that’s why i use it only in emergencies – when there’s no other way.

my mate for today, very smart, she sometimes make fun of me because everytime she ask me for help, i always ask her for any running tests, otherwise i start writing one. anyway, i hope sooner or later she’ll start writing test-first herself. get test-infected.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: