CodeSOD: Switching Your Test Cases

Chris was given a program and told to improve it by adding tests. That was a good start to a terrible experience. Just getting it to build was a chore, as the build files had absolute paths hard-coded into them.

But the real problem Chris ran in to is that it's hard to write tests for something if no one knows what it does or why it does it. The application had no documentation. No comments, aside from commented out blocks of dead code. But comments aside, there was no other documentation. Which left Chris with methods like this to work with:

public int priority(){ switch (this.type) { case 1: case 2: return -1; case 3: case 4: return -1; case 5: return -1; case 6: return 1; case 7: return 2; case 8: case 9: return 3; case 10: case 11: case 12: return 4; case 13: return 7; case 14: return 7; case 15: return 8; case 16: return 9; case 17: case 18: return 15; case 19: case 20: return -1; } return -1;}

It's easy to write a test that confirms what this function does, certainly, but it's very difficult to write a test that proves this function is correct. What even is priority in this context? Is -1 meant to be some sort of error code or is it a very low (or very high?) priority? Actually, for that matter, what is type? While we're at it, why do we sometimes collapse cases together and sometimes don't?

There may be good answers to these questions, though probably not. But Chris certainly didn't get those answers as part of the project. At this point, the application has plenty of tests which confirm the application does what it currently does, which is better than no tests at all, but leaves a lot to be desired.

[Advertisement] Otter - Provision your servers automatically without ever needing to log-in to a command prompt. Get started today!