I agree 100% with Emmanuel.
I've had good luck making helper methods I want to test separately
package private, especially when I put a comment in that the non-
private access is for testing purposes. Then a unit test in the same
package can call the method but user code in a different package
can't. I'm not really thrilled with this approach but it seems to me
to be a reasonable compromise between straightforward class design
and testing convenience.
I think doubling the number of classes is a sure way to eliminate the
chance of any new contributors.
thanks
david jencks
On Feb 13, 2007, at 10:02 AM, Emmanuel Lecharny wrote:
Hi Ole,
I will give you my opinion about unit tests and method protections.
Do not consider it anything else than my personnal opinion, based
on my own feeling and 25 years of coding experience (not always
happy).
On 2/13/07, Ole Ersoy <[EMAIL PROTECTED]> wrote:
Hey Guys,
<snip>
You'll notice that I used a
Class + ClassHelper pattern.
So I can have all the methods public on the Helper,
thus I could easily test them all.
I asked others one the JUnit list if there are any
security risks to having all public methods.
They said not really.
if you ask people who never add any accident driving without a seat
belt, they will tell you that the risk is very limited. private
methods is a kind of seat belt you like to have when you hit a wall.
IMHO, trying to cover all the code with test (ie, 100% test
coverage) is useless, because it's simply impossible to guarante
you will get a 100% coverage ( http://en.wikipedia.org/wiki/Kurt_G%
C3%B6del)
The more that we can do is to do our best.
Now, that being said, about helper classes :
1) a method is private because we don't want to expose it to the
public. When you write such methods, as you can't test them easily,
you have to be very carefull. The parameters should be tested, and
'assert' is a good way to do so. At some point, ypou can also test
those methods simply by testing the public method which use it.
2) having 2 classes instead of one drive you to double the number
or bugs. This is mathematic.
3) Sometime, tests are simply wrong. You may have to double check
the tests, and fix them if needed. If you have a classhelper in
between, you may have to check two classes instead of one (the test
plus the helper class). This is adding some burden.
4) Having two classes to maintain is really problematic. The more
classes you have, the more work you will have to do. All this work
won't be put into the single class, so one can think that this
helperclass drives the developper to loose focus on what is really
important.
5) If the developper has choose to declare a method as private,
public, protected, or with a default protection, it is because he
sometime has good reason. This is somehow the basis of OO design. I
don't want to loose this, I don't want to go back to C or, worse,
Basic.
6) From a user friendliness point of view, I really like to see at
first glance which are the public methods of a class (they are
green in Eclipse).
Ok, now, this is not only my opinion. It's also somthing I will
push strongly if voted. I must tell that I will veto such a
decision (to have all methods public) if asked. Of course, if i'm
the only one to veto such a decision on the project, I will
dismiss, naturally. I'm not threaten anyone, I'm just saying that I
don't think we should change the way we are coding. I try to be
pragmatic : we are writing an Ldap Server, not a giant unit test
system around an LdapServer. We are already have somthing like 3
000 tests, and we add a few every single day, I'm confortable with it.
Trying to reach perfection is insane. Even God can't do everything
perfect : he created mankind :) (ok, for people like me who don't
believe in God, think about the Chaos Theory... )
Emmanuel
--
Cordialement,
Emmanuel Lécharny
www.iktek.com
