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.
> > 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.
> 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.
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.
> 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.
> 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.
'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
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.
