>Testing Cramps

>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?

Another Cramp:

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.

Advertisements
This entry was posted in eclipse, refactoring, testing. Bookmark the permalink.

3 Responses to >Testing Cramps

  1. Matthew Hall says:

    >One thing I've wished EclEmma did was provide coverage tests class by class, rather than running the entire test suite and telling you which code paths were executed across the whole run.I've found when doing TDD that if I run a coverage test only on the specific class I'm working on, then I'm much more likely to get meaningful coverage in the unit tests.For example, if I'm developing Size.java then I will run coverage tests only on SizeTest.java. In this way I can isolate my coverage verification from passive use that might happen in unit tests for other classes.

  2. Scott Lewis says:

    >Hey Dave. If you want other projects to have greater test coverage, then why not contribute test code to them? (and/or encourage someone to do so)

  3. David Carver says:

    >@Scott, because that isn't Test Driven Development which is what I believe developers should be practicing some form. And I have contributed to Web Tools Platform tests for testing various pieces of their UI including Content Assistance. I also write and committ tests with every bug I fix, so I practice what I preach. I've found that having the tests with the code, really does cut down on the number of critical defects that appear to creep through on various projects.Tossing testing off to the community is not the answer, the answer is the committers writing more tests and making sure that the code they write can be tested.Eclipse platform in the past ran code coverage of their tests and published the results. More projects need to do so. I'm working on doing it for the wst.xsl component and the psychopath processor during it's builds.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s