ServletUnit is a thin layer around the HttpUnit framework (reviewed here). An excerpt from the page:
“As a testing tool, HttpUnit is primarily designed for “black-box” testing of web sites. In many cases that may be all you need; however, if you are developing complex servlets, you may wish to test smaller pieces of your code. Sometimes you can isolate them into simple tests using only JUnit. In other cases, you will want to test in a servlet environment. At this point you have two basic approaches available. You can test in a real servlet container, using a tool such as Apache Cactus, which has you deploy your tests into the container along with your servlets. Or you can use a simulated servlet container. ServletUnit takes the latter approach.”
So again, like HttpUnit, ServletUnit is not a unittesting-framework. It is a way to execute complex servlets without the need for a servletcontainer. Before we might want to dive deeper in the API, i’ll try to explain why i think it is deprecated.
Since the advent of MVC-frameworks like Struts there has been a tendency to decouple the view and controller from the model using commands, facades, business delegates, or whichever useful designpattern you can think of, thereby moving the businesslogic to POJOs in order to make it as reusable as possible.
For instance, in a standard Struts application you’ll declare your actions (commands) in a xml-configuration file, extend the standard action by implementing the execute method and call your business-objects. A clean implementation of the method typically is only about 10 or 15 lines – at most, the real work is done in the model layer. When a request comes, a standard servlet (the Struts ActionServlet) redirects the client to a action-subclass which was specified in a request-parameter, calling its execute method.
Seriously, when was the last time you implemented a full fledged servlet?
My point exactly.
