Testing Your Code to Test Yourself

There was a time not too long ago when I was in the same company I work

for today. I got my work done, I completed the tasks/projects assigned

to me, I got paid and I enjoyed what I was doing. None of this has

changed by the way, I still like my job and doing what I do; I also get

paid to do it. During these earlier times (again, not all that long

ago) I also didn’t write tests for my code, it isn’t required (See: Slam Dunk Model) to do so and my code worked; sure there were bugs, but all code has bugs right?

My first introduction to unit testing my code was: “So this thing will notify me with a ‘fail’ message if I change something else later that might make it stop working?? Oh that’s cool!” While I was sold once it saved my butt, I quickly found out that writings tests can be hard. It’s hard if you’re new to it AND you’re not required to write them AND the code you wrote is very difficult to test. It gets easier though and as the tests get easier to write, the code your write will naturally become more testable.

Testable code is is FAR BETTER than untestable code.

Sorry for the bold and caps lock, sorry for beating a dead horse. If you’re reading this and you don’t feel the tone of horses getting beaten to death, I hope this will benefit you. When I wasn’t writing tests, it wasn’t because I was against it, it was because I was ignorant of the benefits of unit testing. When I wasn’t writing tests, it was as simple as somebody showing me

how to write a test. That’s what got me started and it has helped me

immensely.

I used to not write tests. I also used to write bad code.

There’s plenty of people out there who do test, if you’re one of them,

let me propose something. See if you can find somebody in your

organization, user group, group of friends, etc, who doesn’t write

tests, introduce it to them. It could be as simple as “Hey you should

look up writing unit tests.” or as much effort as you’re willing to

share with them.

Please note that this whole time I never mention that I write great code. I never even use the word good. To me it’s about continuous improvement and I can see the quality of my skills improving. For any questions you may have on the subject, I hope you find the following links helpful:

• When should I write tests? – Always. I saw some code from Scott Reynolds yesterday that could “save the world” 😉
• Can you tell me more about Writing Testable Code? – No, but Misko Hevery gives a good presentation
• Does my code suck? – Probably. I know a lot of mine does!
• Are there libraries to help me? – I use NUnit for .Net, which is built on JUnit for Java. There’s also QUnit if you want to test your JavaScript.

This just scratches the surface and I won’t get into Mocking or Isolation frameworks, but you need to start somewhere if you’re not doing so already. There’s plenty of similar blog posts out there to tell you that you should; this time around I just wanted to share why it’s important to me. Personally, it’s the second of the 2 strong quotes from above.

There’s plenty of people out there who do test, if you’re one of them, let me propose something. See if you can find somebody in your organization, user group, group of friends, etc, who doesn’t write tests, introduce it to them. It could be as simple as “Hey you should look up writing unit tests.” or as much effort as you’re willing to share with them. It was pretty simple to get me on board.