> > But if you have to make setPropertiesFileName public, or to make design
> > choices for the component based on the testing framework requirements -
> > no, I don't think that's good. If the component has a
> > setPropertiesFileName it is because that's the intended behavior.
> >
>
> How would you unit test it then ?
Unit testing works great in some cases, but not for everything. When you
need to change the interfaces and code so that it can be unit-tested - you
have a problem.
> 1) Ok, let's take another sample : let's take almost any Apache code that
> deals with Servlet(Turbine, Struts, Jetspeed, ... ). You'll see that you
> have code logic that is mixed with Servlet objects. Now let's imagine that
> you want to unit test a method. You'll have to *modify* it to try to move as
> much of the logic away from the Servlet code to try to build a facade. So
I don't think "you have to unit test a method" is a good enough
argument. You have to modify your test procedure if unit testing doesn't
work for the code - not to modify the code ( there are enough other
reasons to modify the code anyway ). Of course, if the code is not
flexible enough or the API it provide doesn't solve the problems, or it's
too complex - it must be changed.
> Hope I convinced you a bit more, even a slight bit more would make me happy
> .... :-)
You don't have to convince me - I am convinced on the importance of
testing the code, and more options the better. I'm just scared on the idea
to change the code because the unit-test framework can't deal with it.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
