Shawn has an interesting post where he talks about why 100% unit test coverage should be one of your goals. I agree 100%. I’m not sure why anyone would say that you shouldn’t be testing your properties. Don’t you want to make sure they work?
The prevailing philosophy in regards to unit testing is writing your tests before your code. In practice, this happens a lot less than it should. Why should we write our unit tests first?
- Writing your unit tests first makes you design pieces of your software from the clients perspective. After all, you’re writing your code to be consumed. The code itself is not important, it’s what it does for other code.
- Unit tests are meant to test functionality, NOT code! That means if you write your unit tests after the fact, you’re probably not focusing on the functionality. You might be trying to come up with edge cases that might not even matter to the client. It’s harder to come up with good unit tests after the code is written, because you’re not necessarily looking at it from the clients perspective, or from the perspective of the required functionality.
There are two valid ways to increase code coverage:
- Write additional tests – This only makes sense if you forgot to write the test initially. Since you’re tests are verifying functionality, why don’t you already have a test for this particular piece of functionality?
- Remove the untested code – In a perfect world, this is what you would always do. After all, your tests verify that your code has a certain set of functionality. If you have untested code, that code isn’t needed. Why keep code you don’t need?
Here is the basic process I recommend:
- Come up with a rough design in your head
- Write unit tests to test a required piece of functionality
- Write the code to provide that functionality
- Verify that the unit tests pass, fix the code as necessary
- Refactor as necessary
- Run a code coverage tool, and get as close to 100% as possible using one of the methods I mentioned previously.
- Go to #2 and repeat as necessary
1. Write a test for the new functionality
2. Run all tests and make sure that the new one fails
(otherwise your test is pointless)
3. Write just enough code to pass the test
4. Run the tests again to see them pass
5. Repeat
If your code and functionality are not relatively equivilent, then I suspect you have problems. Either you have excess code or you have not identified all your functionality (which is why I disagree with the “write just enough code to pass your tests” theory; it assumes that your first pass on writing down testcases was complete). So yes your unit tests should be testing your properties (assuming you are developing using TDD). If not, the problem isn’t that you need to add additional test cases to cover getting and setting those properties. Its that you need to add additional test cases to cover the functionality that uses those properties (unless you just put them in there for no reason).
What is the smallest piece of code/method/function you need to write a test for? How about the identity function, that returns its only parameter?
In Haskell, where there is no null, and no reflection, if you write a test for the identity function, how do you make it fail?