----- Original Message -----
From: "Alex Fernández" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 16, 2001 1:45 PM
Subject: Re: Test classification
> Hi Vincent!
>
> I think your classification is well thought, but you engrain the test
> method inside each category. As a matter of fact, we use mock objects
> for functional testing, what you call '3: end to end tests'; and it
> should be possible to use different test methods for every category.
>
I see what you mean. I should have phrased it differently. Probably the use
of "Mock Object" has different meaning in everyone's head. I should have
used "Endo-testing" instead mean as it really refers to that paper.
You're right about the different test strategy for each method. What I
wanted to do was to try to make some categorization in order to see where
Cactus was sitting, so that others would understand better. Also, a goal
might be to evolve Cactus into being able to address the 3 needs :
"endo-testing", "cactus way with in-container testing" and "functional
testing" (not end user test cases which should not be addressed by Cactus as
far as I see it).
> What follows is a (long!) description of our current testing
> methodology, or at least our part in it; acceptance tests are the
> responsibility of the customer, and they usually do it manually.
Agreed for the responsibility. However, it would be nice to provide them
with tools that they could use and be trained with - during their on-site
time.
> We
> don't do EJB's, since we have no EJB container.
>
I don't understand. I you do EJBs, certainly you have an EJB container ...
:)
> On a well-architectured system, the servlet should contain the minimum
> logic, and delegate all processing to other classes. Suppose that,
> according to the functional specification, our system must GET a
> parameter 'account', look it up in a DB, and then display the money in
> that account. Object-challenged folks would write the following:
>
> class NonObjectServlet extends HttpServlet
> {
> public void doGet(HttpServletRequest request, HttpServletResponse
> response)
> {
> String account = request.getParameter("account");
> ... // connect to DB stuff
> // get the money from the DB
> int money = resultSet.getInt("money");
> // now we write the page
> PrintWriter writer = response.getWriter();
> writer.println("<HTML>");
> ... // various HTML stuff
> writer.println("Your money: " + money);
> ... // end page
> }
> }
>
> where I have ommitted non-relevant stuff. But, an object-conscious
> developer will write an architecture of classes to do the processing:
>
> class ObjectServlet extends HttpServlet
> {
> public void doGet(HttpServletRequest request, HttpServletResponse
> response)
> {
> // get the account from the request
> Account account = parametrizer.extractAccount(request);
> // get its info from the DB
> AccountInfo info = accessorDB.getInfo(account);
> // construct the page with the Pager class
> String page = Pager.makeAccountPage(account, info);
> // and now, print it
> PrintWriter writer = response.getWriter();
> writer.println(page);
> }
> }
>
Actually, I would even add methods or another class to handle this complete
use case, and I would delegate the construction of the page to a JSP (for
example), but yes I agree with you say ... :)
> where the responsibilities have been shifted to classes Parametrizer,
> AccessorDB, and Pager (instances of which are kept in the servlet).
>
> The point is, now AccessorDB and Pager can be unit-tested
> in a simple way, just putting in fake accounts and account info. These
> would not be mock objects, but test data that should be inserted in the
> DB.
>
That's one possibility but then this is tests that fit into category 3. But
you're right, you don't specially have to go through categories 1 to 4. If
you have enough confidence that your category 3 tests cover what you need,
that's fine ...
> But to unit-test the Parametrizer class, we'll need a TestRequest (such
> as the one I sent on monday). This makes up your 1st category.
>
or 2nd (Cactus).
> Then, when all the pieces are put together, we'd do a functional test,
> or end-to-end test as you put it (3rd category):
>
> class ObjectServlet extends HttpServlet
> {
> public void doGet(HttpServletRequest request, HttpServletResponse
> response)
> {
> ...
> }
>
> static public void main (String[] args) throws Exception
> {
> // initialize the servlet
> TestConfig config = new TestConfig();
> ObjectServlet servlet = new ObjectServlet();
> servlet.init(config);
> // mock request
> TestRequest request = new TestRequest();
> // we place the parameter
> request.setParameter("account", TEST_ACCOUNT);
> // mock response -- will be written on file
> TestResponse response = new Response("output.html");
> // make the call
> servlet.doGet(request, response);
> // now, for a nice end-up, we check the file
> HTMLChecker.checkFile("output.html");
> }
> }
>
> This is a *functional* test, since it checks all of the system -- and it
> also uses mock objects. To be honest, we should also perform test cases
> for empty parameter, no parameter... and check that the system works
> (i.e. doesn't throw naked exceptions). And, we usually do so.
>
> You might think that it still requires developer interaction, since the
> output file .html should be studied by a human to check that it really
> contains the account info. In fact, it does; but only the first time
> it's generated. Later, you just check that no exceptions arise -- and
> this way you can catch 90% of errors introduced.
>
No, you can also use something like HttpUnit for checking the returned
result.
> The next point is to test the system-wide behaviour, including sequences
> of pages. This can also be done manually, or automatically, and would be
> part of the systems testing (your 4th category); and it cannot be done
> with mock objects.
>
agreed. There are some high level tools that help to do that if you wish to
automate it.
> I cannot say that I fully understand your scheme, though, since I don't
> really see the need for a 2nd category, between unit- and functional
> testing. But my point is (finally! :) that you can use different
> techniques at different levels, and they would still fit that category
> nicely.
>
> Un saludo,
>
> Alex.
>
Thanks for that interesting feedback !
Now, the real question : What would you want Cactus to do (choosing from
categories 1 to 4) ?
Cheers,
Vincent.
