Interesting ... Let me try one more time ... :)
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 23, 2001 10:43 PM
Subject: Re: Servlet Unit Testing strategies
>
> > 2) For any test framework that you use, you may have to modify your own
> > class to help testing it ... but this is not bad, this usually brings a
> > better design ... For example : let's say you have a class that uses a
> > Properties file to read some data. Let's imagine you want to test your
class
> > that reads it and retrieve some properties. If you want to test all the
> > cases, you have to provide several versions of this properties file :
some
> > with incorrect values, undefined properties, ... It means that even if
you
> > don't need it, you may have to add a setPropertiesFileName() to your
class
> > so that when you write your test class you can use the different test
> > properties file, ...
>
> 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 is fine if the framework can test the APIs, it's very bad if
> the APIs have to be changed so that the framework can test them. I don't
> think the goal is to create components that can be tested by a certain
> framework, but to create testing tools that can test the components we
> need.
>
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
you're changing your code for a testing purpose .... :) However, it is a
good thing because it make think about your code design and refactor it.
2) I am pretty sure that the next great language that will come up (after
Java) will have features to test as much of the code as possible with the
minimum amount of work : programming by contract style, maybe a way to
specify sets of test environment values and expected results (as part of
your class) that will be exercised during compilation time, ... In that
sense, I would say that thinking about testing issues when designing a
container is probably a good thing !
>
> Costin
>
>
Hope I convinced you a bit more, even a slight bit more would make me happy
.... :-)
Vincent.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
