views:

159

answers:

5

I have this horrible habit of typing the below and not catching it until well into testing:

int i = 1;
int j = 2;
i =+ j;  //i equals 2, not 3 as intended; assign only, + is unary and works on the j

The correct version, of course, would be

int i = 1;
int j = 2;
i += j;  //i equals 3, as intended with additive & assignment compound operator

I have made this mistake a zillion times. It would not surprise me of there is some code out there with a bug in it that escaped a test case. There has just got to be a way to prevent this systematically. Any ideas?

A: 

I think you have to be rigorous in your unit testing. At the moment you're worried about one particular issue, but good unit tests will capture most issues (ignoring threading/loading etc.).

You have to decompose your classes/methods such that you can test each chunk of functionality and ensure complete (or as near as you can) coverage.

Clover (commercial) or Emma (open source) will manage code coverage for you.

Brian Agnew
unit test can have bugs too.
Stu Thompson
Unit tests in practise should be relatively straightforwards, however. I tend to be concerned if a unit test has the complexity of the code it's testing, and it's not obvious as to what is being asserted. If that's the case then I'm not convinced the code has been structured/designed with testability in mind. (Note that all the mechanisms mentioned in this thread can have bugs)
Brian Agnew
Also, as I work in a small, dynamic start up and not a Bank/NSA/whatever, I do not (and will not) have 100% code coverage + 100% test coverage.
Stu Thompson
I don't think being in a bank/whatever is a prerequisite. My work for non-corporate clients has the same coverage metric as for any other. I really think it's the solution, not just for this problem, but for most issues (whether typos or others)
Brian Agnew
I'd also like to catch it on the spot. Immediate negative reinforcement is what they call it, I think. Probably going with the most popular answer here...
Stu Thompson
+10  A: 

Regularly use tools like PMD and/or Checkstyle. Ideally as part of your build process/continuous integration.

You might have to define a custom rule for this, because I don't know if any of those tools recognizes this as a problem by default.

This will not only catch this problem, but also hint at a lot of other potential problems as well.

Joachim Sauer
Hmmm...using checkstyle but have not looked at the rules in ages and run it in an embarisingly long time. Need to go check that out again.
Stu Thompson
+1 for Checkstyle. Used it on a big Java project with Eclipse, with very clever rules (some default, other custom) it was great to catch stupid mistakes and stop worrying about code style/refactoring. Now i miss it dearly on my new, 1 person, C# project under Visual. T_T
Ksempac
+1  A: 

Use standard text utilities, such as

find . -name \*.java -exec grep -H "=+" {} \;
Christoffer
Great for a one off check, but I want as part of my development process. (Just ran it, all is good in my main code base!)
Stu Thompson
+10  A: 

Depending on what IDE you use, if it does syntax highlighting, I would modify the highlighting so that it looks for the pattern =+ and makes it some awful-to-look-at color.

Matt Bridges
"Interactive negative reinforcement"...I like it...
Stu Thompson
Ha, hopefully it will help you break the habbit.
Matt Bridges
maybe I can wire up a small electric shock ;)
Stu Thompson
A: 

As balpha commented, an easy way to find this would be to grep for the "=+" in code. It is probably never intentional.

Avi