Future of java and testing

Question

So I cry a little inside every time I have to change my design so that I can test things. Now I don't mind breaking the functionality of a MDB out into a POJO..that's fine....but I HATE making private methods public just do I can test them.
Are there any plans to integrate unit testing into java and to allow testing of private methods?

Answer 1

Can we rant about testing here? Oh goodie :-)
I've never made a private method public or protected for that reason, or even ever wanted to test a private method. I only test everything that I promise, and I don't promise even myself anything about my own private parts :-).
If I have some private functionality that is complex enough I do want to test it in itself, I'll delegate that part to another class and test that. In my experience, any refactoring I do to increase testability, I would also end up doing for readability or reusability. And it's never included increasing a method's visibility.
public void testJunk{
MyClass mc = new MyClass();
mc.myMethod();
}I do write such tests actually, albeit very very seldom. And I don't have anyone telling me I should have X% coverage, which I agree is moronic. Metrics are overrated. I do force myself to keep my test coverage of publics very high, because I've never regretted spending time to write a test, but often regretted not having spent that time.
Now, I assume in the above example myMethod is not a method with an effect that can be asserted, otherwise it's just an incomplete test and there should be more, not less. But even if you can't assert anything about it, you're testing that default instantiation followed by that method call doesn't throw. You're expecting it, you're promising it at least implicitly, so why not test it?
That all said, there is something about testing and visibility that bites me. I don't want to put test classes in the same package as the testees. As a result, every class and method that I test is public where it could possibly have been package access. So I do increase from package to public when I promote a class from "too dumb to be tested" to a "test-worthy" class. I'm okay with this in itself; if I'm unit testing it, chances are it can be used in a different context anyway.
What does bug me is that I'm effectively skipping package access, not using it as it's intended, and trading the benefits that can come with it for maintaining this way of testing. Whether a class should be tested or not says more to me than whether it should be public or package, and my way public is synonymous for tested (I often enforce this with static code analysis: if it's public but not tested it will be flagged as "could have lower visibility" or some phrasing to that effect). But that's not the Java way of using public and private access. Oh well.
So, I've been wondering about this, what do you people do? Do you decide about public/package a priori, and then put the test class in the same package as the testee? Or do you not test it if it's package access?