You are responsible for making that feature work. Write a test. Just do it…

Today the PM of a project I am working on sent an email with a small list of issues that we needed to get resolved before shipping an early build to the customer for a weekly review. In his list of issues MY NAME was tagged next to a feature that I KNOW was working. I dev’d it, tested, saw it work.

Now the project I’m working on encourages unit tested code, which is a fantastic project to be on since I am a big proponent of Unit/Integration/Automated tests. Heck I wrote a tool to help run them easier (StatLight).

What I did.

The problem was this. I dev’d a feature out in like 5 minutes, took about 2 seconds to decide if I should write a unit test to prove my feature worked and this is where I failed. Manually verified my change checked in the production code without its test and I was hurriedly moved on to the next task.

About 20 min later I get a quick I.M. from a co-worker saying he had a small merge conflict in the file I just checked-in. Quickly told him how to get around his merge issue (not realizing after he checked in) that my “quick 5min dev task” was accidently removed in the merge.

What I SHOULD have done!

What I should have done was write the 2 lines of test code first. (you can argue test after/test first, I prefer test-first). Proven my code wasn’t working, by running the test, and then implement the 5 min feature making the test pass. Then when my co-worker ran into his merge issue.

Test would have failed telling him his merge didn’t go as planned.

This would have also avoided

• PM wouldn’t have had to discover the issue, Screenshot and write up an email.
• I wouldn’t have had to peruse source control history to understand why my “working” feature wasn’t working.
• I wouldn’t have had to willingly confess my sins in this post.

If your feature doesn’t have a coinciding automated test. How do you know it’s still working?

Happy Testing!