RE: Ok, let's talk about testing approaches!

[Vincent Massol <vm...@octo.com>]

> -----Original Message-----
> From: laurent.duperval@masq.ca [mailto:laurent.duperval@masq.ca]
> Sent: 16 April 2002 12:56
> To: Cactus Mailing List
> Subject: Ok, let's talk about testing approaches!
> 
> Hi,
> 
> Now that I've got the mechanics of this going, let's talk about
actually
> using it!
> 

:-)

> I just got a document from my QA analyst which a whole bunch of test
cases
> that she wants us tor do on our code. One section tests for missing or
> invalid values for parameters. We have a (POST) request that takes
about
> 18
> parameters as input. How would one go about testing each parameter for
> incorrect and/or missing values? Should I be writing one method per
> parameter? Or do only one test which tests each parameter one after
the
> other? Or another approach?

A junit test case is supposed to test one path of execution at a time.
Thus in your case, if you have 3 paths for each parameter (one invalid
case, one valid and one where you do not defined the needed parameter),
that would be 18 * 3 = 54 test cases. However, in reality it can be less
than that. For example, you may have a general algorithm to test for
missing parameters and you would just need to ensure the algorithm is
working on 1-2 cases to get a good confidence you're fully covering all
cases, etc.

> 
> Another question I have is: how do I test the servlet only? By that I
> meant
> that our servlet extracts all the parameters from the request and then
> hands
> them off to a handler which knows what to do with them. If I want to
only
> test the servlet, I think I need to use somethihng like Mock Objects,
no?

yes. Another option is to use AspectJ but you'll need to understand the
concepts first. In other words, there is a learning curve. So yes, I'd
suggest MO.

> That way the MO will react somewhat like the Handler would. 

No, you're talking about stubbing. I'm talking about Mock Objects
(www.mockobjects.com) where your test case tells the MO how it should
behave.

> But the
> examples
> I've seen of MO's don't seem to apply well to servlets. 

Why ? The mockobjects project even provides mock objects for Servlets.

> The White papers
> and
> documentation I've read tend to show that the signatures of the
methods
> are
> changed to accomodate the use of MO's. 

It depends if your code is well written or not. If it is written with
the concept of Inversion Of Control (IOC) in mind, then it is very easy
to use mocks. One good thing about mock is that it forces you to improve
your code.

In your case, it is simply a matter of having a setHandler(Handler
handler) method in your servlet that is called in the init() of your
servlet for example. Then, you would write something like this in Cactus
:

public void testXXX()
{
  MyServlet servlet = new MyServlet();
  MockHandler mockHandler = new MockHandler():
  mockHandler.setExpectedXXX("vdkfjdkfdl");

  servlet.setHandler(mockHandler);

  // Perform asserts
}


> In the case of a servlet's
> process()
> method (which would be the one to call out Handler), I can't really do
> that... Hmmm... Unless I make it call another process() method which
has
> the
> hadler as a parameter. That's one way to do it, I guess. Any thoughts?

See above.

> 
> Any feedback from anyone who's done something similar would be really
> appreciated!
> 
> L

Hope it helps,
-Vincent

> 
> --
> Laurent Duperval <ma...@masq.ca>
> 
> MURPHY'S_LAWS_OF_COMBAT:
>  12. A "sucking chest wound" is natures way of telling you to slow
down.
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:cactus-user-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:cactus-user-
> help@jakarta.apache.org>
> 




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>