Preamble
---------
I have been thinking hard :) during the last 2 days about Cactus v2 and the
unification of MO, IC and PF tests. We have been discussing it for about 2
weeks now on the cactus mailing list, thus gathering ideas and opinions.
Also, I have recently understood what Mock Objects really are (I still may
be wrong as I am still very novice in this field !) and they are not what I
thought they were ... I thought they were a simple implementation of an API.
That's a possibility but it is probably not the best way to use them because
it means we need to implement the API logic in the mock implementation,
which may be very hard to do. Rather, the correct way is to not have any
logic at all and tell the Mock Object how it should behave for the current
test, i.e. tell it it should return such value, tell it it should return
such exception, ... In some sense you externalize the logic to the outside
(in the test case).
If you think about it, you'll find that with what is described above,
writing a MO test case is completely different from writing an IC test case.
In IC, you set the state of your object so that by knowing how it works
internally, you know it will have such behaviour when you call such method.
In MO as described above, you don't care about the state of the mocked
object, you simply care about what such method will return (or what
exception it will throw), thus you don't set state on the object, you set
expected behaviour for methods.
New proposition
-----------------
I am now convinced (thanks to my better undestanding of MO and thanks to
Thomas Calivera and others on the list) that it is not the correct time for
Cactus v2 to try to integrate MO with IC and that they do not blend well.
However, it does not mean it is not possible. It means that with my current
understanding I don't see how Cactus would be able to keep with simplicity,
ease of use and consistency if we were to integrate MO, IC and PF. On the
other hand, I am also very interested by Mock Objects and I will continue to
study them by collaborating on the SourceForge mockobjects project
(www.mockobjects.com). Maybe this new knowledge will give me new ideas for
integration or would even further convince me it is not the correct way to
simplify unit testing. I encourage everyone who is interested in MO to help
us on the mockobjects project in order to make it a thriving project.
The idea is to keep the 3 following frameworks separate (but why not with
bridges between them) :
- Cactus, specialized in unit testing server side java components using an
In-Container approach (IC),
- HttpUnit for functional unit tests (PF),
- MockObjects.com for mock implementations (MO)
If you agree with this new proposition, our goal is to continue to improve
Cactus in its IC approach (and there is still a lot of work to do!),
especially in the following areas :
- documentation. We need to provide even better documentation (with trails
for example, like the Java tutorial and also rework the existing
documentation to better structure it and add missing things),
- better taglib testing support
- better EJB testing support
- better JSP testing support
- Servlet Filter testing support
That's already quite a lot!
I believe Cactus is still very useful even when knowing the MO approach for
the following reasons :
- Cactus gives you a much better confidence that your tests are going to run
fine where they will be deployed (i.e. in the container where they will run)
- Cactus lets you test interaction with the container,
- MO is not always applicable (especially if the code to mock has not been
implemented with MO in mind and if it lacks interfaces),
- MO is more difficult to understand and doing it well requires training and
experience,
- MO may mandate changes to your code (so that you can initialize any part
of your code with mocked domain objects). On the other hand MO will make you
change your code but it will help you write better code,
- Cactus lets you test the deployment of your code as well as your code,
meaning you discover sooner rather than later deployment issues and
container setup,
- MO provides very fine-grained tests which necessitates 1/ a very strong
commitment to unit testing and 2/ that you'll also have to other functional
tests afterwards to ensure your code works. On the other hand Cactus
provides a middle ground between very fine grained MO tests and between very
coarse grained Acceptance tests, thus giving you a good confidence in your
tests.
- Unit testing of EJBs may be easier with an IC approach rather than an MO
one (to be verified)
- (complete with your own ideas)
Conclusion
-----------
* Cactus will continue (if we agree of course !) to implement IC tests and
will continue to offer a simple solution for unit testing server side java
code, always trying to be simpler of use (through even better documentation
and possibly through new mechanisms) and trying to cover as much as possible
the J2EE specification.
* Cactus is not incompatible with MO and MO can be used within Cactus test
in order to simulate API that Cactus do not address (like Struts Action for
example, ...)
* Cactus will have a "brother" framework, which is the MockObjects.com one
that will also address unit testing but from the MO perspective, adding a
complementary approach. The distinction between the 2 will be clearly
explained on the Cactus web site, with examples and explanations of when to
use one instead of another in the development process.
* Cactus will integrate with HttpUnit in order to provide strong assertions
capabilities in the endXXX() method for asserting output stream results
A last note
-----------
You may find it strange that I changed my mind in such a radical way ...
especially as I was the one arguing the most about the integration of IC, MO
and PF ... ! I certainly would have liked to see this happen. However, I
also know when it is time to back out ... (thanks to you!). My ultimate goal
is to do what is best for Cactus and I find that the proposal here is the
best course for Cactus (tell me if I am wrong!). I would also like to take
more time to learn better MO (which is one reason for giving a hand on the
MockObjects project).
Any comment ? I'm sure there will be plenty ... ! :)
Thank you very much.
-Vincent Massol
