Hi Vincent!
I think it's a worthy goal. Unit-testing is, IMHO, the most important
part of coding -- it's a necessary verification that the developer makes
for herself, and for the rest of the team. We now include unit-testing
in all of our classes, and do not consider code to be complete until
unit tests are OK -- a technique borrowed from eXtreme Programming.
I just have a worry on terminology. The "service" that a container could
and should provide, I'd rather call 'integration tests'. Once all of the
classes work, it's time to test that they play ball together; the best
place is through the servlet/JSP/EJB. If a program is modular enough,
these objects will do little themselves, and will rather rely on the
regular classes to do the job.
For example, we use servlets as our server-side technology. They are
used as the Controller in a MVC paradigm -- the real work is done in the
Model, and the results are passed along to the View, where the next page
is generated.
Therefore, a servlet unit-test assures us that the controller works OK
-- and that means that the whole MVC scheme is integrated. That's why it
plays as an integration test in our project.
Notice that it's got nothing to do with black-box (or functional)
testing, where you do not know the inner workings. Here we place exactly
the parameters and headers required by the application, and so take
advantage of our knowledge of the system.
Un saludo,
Alex.
> Vincent Massol wrote:
>
> I will be writing a web page explaining the far goals of Cactus that
> I'll put on the Cactus web site.
> I wanted to have your advice and opinions before writing the page and
> posting it.
>
> The ideas below represent my personal view on the subject of "the
> Future of unit testing server-side components".
>
> The goal I had (which I still have) when writing J2EEUnit was to try
> as much as possible to offer a server side unit testing framework for
> all kind of java components. However, depending on the specifications,
> it is more or less easy. Sometimes, it is even not feasible. I believe
> that we will see more and more components in the future. By components
> I mean pieces of code that executes in a container. The container will
> provide more and more services for the components (like transactions,
> security, life cycle, persistence, interfaces - like web services -,
> logging, ...). Thus, it will become harder and harder to write a
> generic test framework for these components. The ultimate goal that I
> would like to have for Cactus is to make specifications writers and
> more specifically container developers aware of this problem and make
> them aware that unit tests are indeed necessary. The achievement would
> be to come up with specifications and impementations that *include*
> unit testing (and testing in general) as *part* of the container
> specifications, thus allowing independent (and *standard* in term of
> interfaces) testing modules to be plugged into the container. IMO,
> this the only way to go. The Jakarta project is hosting the Tomcat
> servlet container and a first goal could be to try to design a
> container specifications extension for Tomcat that would include
> unit testing. In other words, provide another service for components
> running inside Tomcat : a unit testing service.
>
> Note: I'm not saying this would be done tomorrow. It is rather a
> guideline that I'd like to have for future developement for Cactus.
> The goal being to try to go as far as possible for unit testing
> components. When the wall is reached (meaning it is not possible to go
> further using the standard specifications), propose modified
> specifications or extensions. Gradually try to make these extensions
> accepted so that they will in turn become a standard.
>
> What do you think ? Do you like that goal ?
> Do you think it is feasible ?
> Do you think unit testing awareness (and testing in general) is mature
> enough ?
>
> Vincent Massol.
>
