----- Original Message -----
From: "Alex Fern�ndez" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 17, 2001 3:48 PM
Subject: Re: Cactus Roadmap & V2 Propsal RFC
> Hi Vincent!
>
> Vincent Massol wrote:
> > > I would argue that what you are doing by having separate base classes
for
> > IC
> > > and MO is, in effect creating two frameworks that just happen to exist
in
> > > the same package. Is this is a bad thing? I do not know. Question of
> >
> > Yes, but you only need to download, install and read the doc. for a
single
> > framework.
>
> I was under the impression that mock objects would be used just as
> another servlet container: you choose to run the tests for Tomcat 3.3,
> Weblogic 5.1 and/or Mock Objects.
>
exactly !
> > > If I were only choosing to do MO testing, why would I use Cactus? Why
> > would
> > > I not just use jUnit and spin my own mock objects or use the ones that
> > Alex
> > > posted awhile back? As I understand it, there is no need for the
> > beginXxx()
> > > and endXxx() methods when using mock objects. Am I wrong?
>
> Yes and no. beginXxx() is necessary anyway to do the setup. If you only
> want to catch possible exceptions, you wouldn't need to do endXxx(); but
> if you wanted to check for bugs in the resulting HTML or something like
> that, living inside Cactus would be a big plus -- even better now that
> HttpUnit is willing to lend its powerful validating capacities.
>
yes but it is true that with mock objects you don't need explicit beginXXX()
and endXXX() methods. Everything could live in the same testXXX() method.
However as you pointed out it is need for IC.
> > That would be an option for you of course. However Cactus will provide a
> > single place where to look and will contain full range MO implementation
for
> > all J2EE APIs. Maybe Alex will only provide for Servlet API and maybe he
> > will not cover all APIs of the spec. The idea is to gather our efforts
in a
> > single place and make the resulting framework a defacto standard. For
the
> > moment, there is not a single mock object framework that I see as a
standard
> > framework. The idea is to create this ... :)
>
> Of course, I can only help at the moment with the servlet spec. I will
> soon need to do unit-testing for EJBs, and will try to do it with mock
> objects.
>
Great to hear ! I shall be releasing a base implementation of Cactus v2
quite soon (give me 2 weeks more ...) and it would be great if we could use
this base to comment and build on it.
> But, anyway, Cactus doesn't do EJBs right now. It will be interesting to
> look into doing a "mock EJB container" when it's necessary.
>
Yes that will be very interesting.
> > Now, I have sent an email to the guys doing the Sourceforge mockobject
> > project (see
> > http://sourceforge.net/forum/forum.php?thread_id=121222&forum_id=57634).
> > Very quickly, the idea might be to start a new project on Jakara-Commons
> > (provided this is accepted) that will a reference place for MO
> > implementations. Then make Cactus use it internally. Cactus would be the
> > umbrella project. Person who want nice doc., a single place where to
look
> > at, a unified way of writing different kind of test cases, ... would use
use
> > Cactus. People who would wish to use only "raw" MO may not use Cactus
...
> > But don't forget that MO is not the panacea either ...
>
> It's fast and convenient -- it does not catch container bugs.
It's not a problem of only container bugs. It is also a problem of getting
the Mock implementation right ! To give an idea of what I mean, let's
imagine I would like to mock the HttpURLConnection class, and more
specifically implement a mock getInputStream().
A first implementation would be something like :
public class MOHttpURLConnection
{
private InputStream m_InputStream;
public void setInputStream(InputStream stream)
{
m_InputStream = stream;
}
public InputStream getInputStream()
{
return m_InputStream;
}
}
... however this is utterly wrong ... :) and will let a lot of bugs
uncovered ...
If you look in more details, you realized that you need to catch the
following cases :
- if the URL connection is not set for input (setDoInput()) then it should
raise an exception,
- if there is an error using the input stream, an IOException should be
raised,
- if the URL connection has already opened the socket to the target URL, it
should raise an exception,
...
So, having a correctly behaved MO implementation is not so easy and is not
perfect at all ... Implementing it correctly can be very tricky, may need a
lot of testing (!) and iterations. So in order to be usable, we can agree
that it not _necessary_ to implement it 100% correct the first time and that
you will improve it over time and more importantly that we will need to run
IC tests or functional tests to verify it effectively works.
>
> > Here are some brainstorming ideas / issues / questions :
> >
> > 1/ How do you tell a test case which kind of test it should run : There
are
> > 3 types : IC, MO and pure functional. Is this choice done inside the
test
> > case by calling an API or externally like in a XML or properties file
where
> > you have all your tests listed as in :
> >
> > com.my.MyTestCase1.testXXX1 = MO
> > com.my.MyTestCase1.testXXX2 = IC
> > ...
> > com.my.MyTestCase2.testXXX1 = PF (Pure Functional)
> > ..
>
> As stated above, ideally mock objects would work as another container.
> So, no need to choose beforehand.
Well, that's the goal but the question is : how do you implement it to be
transparent ?
The real challenge is that the architecture is different with IC and MO. For
IC there is an HTTP connection made and there is a proxy on the server side
... Hey, wait a bit, I suddenly have an idea ...
Why not implement a mock (or rather a simple) HTTP server (or simpler yet, a
mock HttpURLConnection that would be used when doing MO tests). The goal is
to have the same architecture for both MO and IC and then the "client" part
of Cactus would stay the same and on the "server" side there will be a
factory that will return either real container objects or MO ones ... Yes,
good idea Alex .... :-)
There is still a problem, it is the IC test initialization data. For a real
IC test, these data would be defined in web.xml ... There is another way as
the one mentionned in my previous email (generation) ... It would be to use
a web.xml file even with MO tests ... Or we could provide 2 ways and the
test writer would choose :
- either put def. in web.xml and they will be available automatically
through the ServletConfig object (be it the real IC one or the MO one)
- either call a ServletConfig.setXXX() (but that would mean that for IC
tests, the data would not come for web.xml and thus this part of the process
would not be tested but that's only one part of the system so that may be
acceptable).
Anyway we need to sort out how we would like to use web.xml for IC tests
because we have reached the limits of the current Cactus v1 solution of
having a single redirector entry in web.xml ... For example if we wish to
set authentication or have init parameters different for each test case, we
need to be able to define several servlet entries in web.xml (for example)
like ServletRedirector_<testcase name>, which will contain properties
dedicated to <testcase name> or something alike.
>
> 'Functional tests' would be more or less equivalent to 'unit tests in a
> chain'.
>
> Now, I don't like putting meat inside a servlet. Unit tests apply to
> unit functionality, and that should be in different classes. So, I see
> all tests done on a servlet as functional -- they apply to many
what about the Controller in an MVC model ? Even if you put all the code
logic in another class it still need to access Servlet API objects. And
wrapping all of these objects into your own objects is something a lot of
pain for not much ...
> different classes working together. Probably, even different servlets
> chaining and so. That would rather be your 'end-to-end testing', but I
> don't think it's so different from functional testing.
>
> You probably refer to something different with that 'Pure Functional'
> stuff, anyway :)
>
> I'm getting lost with the rest of your message, so we'll leave it for
> later.
>
> Un saludo,
>
> Alex.
Thanks Alex
Interesting discussion that triggered some ideas in my head ... :-)
-Vincent
