This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
James Dekker wrote:Don't most test cases use this convention:
No, they use whatever they need to test. You *could* use assertEquals(isValidCode(group), true), but it's silly, sort of like return (foo == true) ? true : false.
Can you elaborate on this?
Not much to elaborate, but:Personally, I'd implement the code under test as a map, rather than a ginormous if statement. I'd also be pretty cautious about this--this is one of those kinds of methods where if there's suddenly another valid group, you won't necessarily know to test it. Whereas if the valid groups are in a map, you have a list of the valid groups you can use to test. Of course, then you're just testing the JRE's implementation of Map.contains(), which seems equally silly.
"assertTrue()" doesn't have an "actual" argument -- it accepts a boolean, and the test passes if the boolean is true; so your assertTrue() call would just look like:
assertTrue("Code doesn't belong in group", MyHelper.isValidCode(validCodeGroup[i]);
There are a few other things you would test: first, test that a bunch of non-valid codes return false -- i.e., define another array "invalidCodeGroup" and then try
assertFalse("Code doesn't belong in group", MyHelper.isValidCode(invalidCodeGroup[i]);
I'd also test lower-case valid codes, to make sure the method returns "true" for them too.
Finally, you'll probably want to test what happens if you pass in an empty string (should return false) and what happens if you pass in null (should return false, I'd say, but the actual method will throw a NullPointerException, which I think should be fixed.)