Simulate real servlet container in unit test

[Sky Loi]

Hi, java experts,

I have to make unit test of servlet which acted as the same as in real container. The requirements are:
1. Setup a test servlet container working as real one (e.g. Jboss).
2. Make multithreaded unit test servlet calls to this test container.
3. Anyway, simulate everything as the real ones.

It would be appreciated if you could share your idea. Thank you.

[Ilja Preuss]

Well, obviously, if *everything* needs to be like in a real container, you will *need* a real container. No way around that.

Can you tell us more about this requirement? Where is it coming from?

[Sky Loi]

I have a online service system providing web service via Servlet and would like to simulate the real env (e.g. multithreaded client requests, simulate mock container server to handle those requests) in the unit testing. It is to check if the internal service works in extreme multithreaded env.

So far, I am using the Jetty server (org.mortbay.jetty.Server). But I suspect this server instance has some different with real container.

Do you have idea?

[Joachim Rohde]

Hm, I guess JMeter (http://jakarta.apache.org/jmeter/) is not *exactly* what you are searching for, but maybe it's a start and you can extend it so that it fits for your task.

[Sky Loi]

Hi, all above,

Thanks for idea. However, it seems that Jmeter is only simulate the client side and create multithread requests to server. It does not provide server side simulation (out of container).

Currently, I have done with a simple client side multithreaded module but still has no idea how to start with server side simulation.

[Jerwin Louise Uy]

Try using Apache Commons HTTPClient object.

Regards.

[Sky Loi]

Hi, Jerwin, thank you for your reply. But Apache Commons HTTPClient is also on client side. My concern is on server side building.

[Jerwin Louise Uy]

I think you can only do so much with a simulated servlet container. Note that simulated servlet container will be based on the servlet specifications, therefore implementations will be based on the vendor who will implement it but there exist a guarantee that it must conform with the specifications.

Therefore, a generic servlet container in Glassfish will behave the same way with the servlet container in JBOSS.

Thus, I doubt a simulated servlet container will behave differently in the real servlet container because they are based on the servlet specifications unless the implementation of the servlet specifications has a bug of some sort.

Regards.

[Pat Farrell]

I don't think you are talking about a Unit Test as commonly defined. Its fairly easy to build mock objects to test a properly constructed servlet, but once you get into multithreading, or testing "everything" you are way past unit testing.

Sounds to me like you are looking for a system test, end to end. If so, you need to emulate a browser. Other have posted some suggestions upthread.

[Ilja Preuss]

I'm confused - as far as I can tell, Jetty *is* a "real" container.

Also, there will also be a difference between a simulation and the real thing - otherwise it wouldn't be a simulation, by definition.
[ October 08, 2008: Message edited by: Ilja Preuss ]

[Jerwin Louise Uy]

Yes. The implementation of the servlet container will be "different", but the API in which it was built remains the same. However, the servlet container will behave the same way as it was defined in the specifications.

Just imagine if vendor A were to implement their own version of HttpServlet without conforming to API programming. Contracts between API calls in the servlet container were already defined for the vendors to implement.

Regards.

[Sky Loi]

Hi, all, many thanks first for your advice.

I actually need to do a full and real-simulated test with specific container provider, e.g. Jboss. But this test need to be done in unit test period. This is my dilemma.

My current proposed approach is to use Cactus (in-container) and bring Jboss env into the test as I only two weeks schedule, and the mock objects to simulate a real container is big and complex approach.

Do you have any experience and idea about in-container servlet test? Correct me if I am wrong.

[Ilja Preuss]

Originally posted by Sky Loi:

I actually need to do a full and real-simulated test with specific container provider, e.g. Jboss. But this test need to be done in unit test period. This is my dilemma.

*Why* do you need to do that? And what exactly do you mean by "unit test period"?

[Sky Loi]

Hi, Ilja, it is good question and bring me a more clean idea.

So far, with all others' advice, my final goal is to have a automatic integration test with JBoss and Maven.

I have developed a small client based on Junit to simulate and generate multithreaded requests to target server.

There are several potential options:
1. In Maven integration test phase, using Maven plugin cargo to deploy/start/test/stop/undeploy in Jboss.

2. Using Cactus framework to have in-container test.

3. Develop sophisticated mock objects to simulate real container.

I prefer to option 1 as it is easy and save my time as I only have two weeks for my commitment. Option 2 bring me a new framework and there is learning curve. I was told the Cactus configuration is not easy. So far, I do not consider option 3 as the time dose not fit me.

Does anyone has more suggestions?

[Rama Krishna]

I am not sure what the conclusion of this post is, as the discussions and comments left me more confused!

I am planning to do similar simulate-real-servlet-container kinda tests, I believe that it means that I will be able to create and simulate a request by sending a populated formBean to our Struts Action classes along with normal unit testing with multi-threading to test multiple user connections at the same time.

I need suggestions as to what are the best and easily to get started options in testing Struts applications?

Thanks
Rama