Junit

Sure, with reflection or a reflection framework like this accessor utility I forgot the name of - PrivateAccessor? (Google will help).

People will tell you that you shouldn't test private methods, though.

IMO it makes sense if you want to run regression tests (don't rely on implementation), but during development, I think that's nonsense, because it's the quickest wa to find out whether parts of your encapsulated logic work correctly - you can test *before* you have all your stuff finished.

CeciNEstPasUnProgrammeura at 2007-7-9 6:25:55 >

> ok...here i change my wordings. (Though i know the

> benefits of having static inner test classes, i

> really shouldn't have said its a best practice.)

>

> I recommend you to use static inner classes.

Please explain why. I've written a lot of JUnit tests, and I've never seen a reason why a static inner class would be beneficial.

Do you mean a static inner class to the code you intend to test, so you can get access to private data members? If that's true, I'd have to disagree. I think one of the greatest benefits of writing JUnit tests is the fact that it is external to your class and forces you to view it as a client would. Testing aside, I find that this subtle change in viewpoint has a beneficial effect on my designs. I don't think it would be the same if I wrote the test as an inner class.

Besides, doesn't that arrangement make the test class a permanent part of the shipped code base? It'll increase the size of your deployment package.

Neither Spring nor Hibernate, two popular open source frameworks, write their unit tests as inner classes. They're separate source trees. Spring is pretty rigorous about theirs. They have 70% or better code coverage. I think they know how to write JUnit tests properly, and static inner classes isn't the correct way.

%

duffymoa at 2007-7-9 6:25:55 >