At 5:22 PM +0100 7/4/01, Vincent Massol wrote:
>I still don't understand why you would want to maintain a state ? Especially
>as HTTP is a stateless protocol ...
Because web sites have to maintain state; that is in fact the reason for cookies: to
allow multiple calls to share state.
>Let's imagine I have a method that sets a variable in the session and I have
>another method that reads it. Are you saying you want to first call the
>first method and then the second ? If yes, then it is not what I call a unit
>test as it involves 2 methods.
It depends on how you define your unit. I am unaware of any definition of "unit test"
that states that it must test exactly one method of a single class. I have seen
people use your definition; I have also seen people find it perfectly reasonable to
define a unit test as testing anything not directly accessible by a user, or even some
things that are. XP uses the definition that a "unit test" is any test written from a
programmer's perspective to ensure that the code works as the programmer intended it
to.
> In cactus, you have access to all the
>implicit objects before running
>your test so you can always set up the correct preconditions (session, HTTP
>parameters, cookies, ...) before running the test and thus there is no need
>to maintain any state.
That is very possibly true, which is why I said I was not sure how important this
feature would be in most Cactus-style tests. On the other hand, depending on how the
state is managed from step to step, it may be preferable to use an earlier method /
HTTP request to do the setting up, so that your tests are not excessively brittle, or
dependent on internals.
--
------------------------------------------------------------------------
Russell Gold | "... society is tradition and order
[EMAIL PROTECTED] | and reverence, not a series of cheap
| bargains between selfish interests."
http://www.httpunit.org | - Poul Anderson, "Iron"
