Testing Your Code to Test Yourself

A rhinoceros beetle (aka bug) - CraigPJ

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:

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.

Related:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Chris Missal

Oh hey, I'm a Senior Consultant for Headspring in Austin, TX. I've been working in software professionally since 2006 and I really, really love it. I'm mostly in the Microsoft world, but enjoy building computer things of all sorts (to be vague). When I'm not slinging code, I'm probably out and about slinging discs, bowling balls, or good beer with great friends.
This entry was posted in Testing. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.lostechies.com/members/mbratton/default.aspx mbratton

    I’ve seen some really bad code (with some really bad unit tests as well)

  • http://www.lostechies.com/members/chrismissal/default.aspx Chris Missal

    @mbratton

    Maybe I should have been more specific in saying “easily testable” code. I think code can have working unit tests, but can still be considered “untestable”.

  • http://www.developsense.com Michael Bolton

    Maybe I should have been more specific in saying “easily testable” code. I think code can have working unit tests, but can still be considered “untestable”.

    What do you consider “untestable”?

    —Michael B.

  • http://www.lostechies.com/members/chrismissal/default.aspx Chris Missal

    To name a few: classes that do too much, “new” operators inside constructors, static methods that do work, classes that rely on unavailable concrete services (not abstractions of these services), etc.

  • Mihai Mahulea

    Very good post.

    From my experience I think there should be a clear difference between TDD and unit testing.
    Writing all test sometime after a good amount of code piles up isn’t a great idea.

  • Serhat Özgel

    Misko Hevery actually has more than one good presentations about the topic. Search for “clean code talks” on youtube.