>At times it is very easy to tell when some code is not written using techniques like Test Driven Development. In particular when I see classes that make liberal use of protected or private inner classes. Now there are valid times to use inner classes, and they are even very useful when you are creating mocks for your test frameworks. However, in many cases, I feel they make the code more difficult to read, and in many cases they can be implemented just as conviently as regular classes. Opinions will vary, and as I said there are some cases where it is necessary. I also tend to have the same opinion about Threading but that’s another blog entry.
Now you could test your inner classes by embedding the test as an inner class itself, but that is just messy. I personally like to keep my tests in a separate project from my code that it tests. Inner classes seem to promote your testing to that of functional testing. The reason is you end up having to test more than specific units of the code, you end up testing a work flow or how objects are interacting with each other.
I just do not find that inner classes promote a test driven approach or make it very easy? Is there something I’m missing? Are there some good articles that don’t use Reflection to test classes and methods with inner classes and anonymous inner classes?
The other cramp I have is the lack of code coverage metrics I see for various projects. I’ve found programs like ECLEmma to be invaluable to letting me know what parts of my code are actually be executed. It has on numerous occassions pointed out where I need to provide more coverage, or where my test suite is weak in the coverage it provides. I used ECLEmma through out the development of the PsychoPath Processor and the W3C Test Suite provides about 73% coverage of the code. There are portions of the code that just aren’t executed, like Static Type Checking and Normalization, all of which are clearly indicated in the coverage reports. These are known areas that haven’t been fully implemented, but it has also shown a few places where the existing test suite needs a bit more improvement and coverage.
Unless you are periodically running coverage reports, you are only guessing at how much of your code is actually being executed by your test suite. I’d personally like to get that extra 7% coverage for PsychoPath to get a better comfort level, but I already know that 73% is far more than most projects have now.