• Post Reply Bookmark Topic Watch Topic
  • New Topic

How to unit test server side components?  RSS feed

 
Vicky Roy
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
Hope you people have faced similar situation of testing server side components. Please share.

It may be any component from servlet to EJB, may use any technology like Spring... may have dependency for database, web service, jndi etc. We may have issues for transaction handling for db also...

What all approaches we have. Any book/link/reference.

Thanks.
 
Rodion Gork
Ranch Hand
Posts: 47
1
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm sorry but it is not clear what exactly do you mean. Unit-Testing of server-side classes is nothing different from testing anything else - as you want to test only class itself. For example if you mean to test some MyServlet#doGet method, you instantiate the object, then call doGet passing to it some mocks of "request" and "response" parameters. You set necessary values on "request" and then check that proper data were set on "response".

If your servlet performs whimsical printing to response.outputStream and you feel trouble with testing this, you should come to conclusion that your doGet method has poor architecture. I.e. if you are serving some data to output (e.g. JSON), you should instead prepare this json in separate method, cover it with separate unit-test and then only call this method in your doGet. Unit-test for doGet then should only check that whatever is served by such method, is printed correctly.

If you print the whole JSP-generated response in the servlet - then you should feel that it is not correct to test it with unit-test. You should prefer switching to proper MVC architecture and while covering M and C with unit-tests, Views could be tested with things like Selenium, if necessary.

The same with anything other. E.g. with Spring you will have Controllers which should be tested in similar manner. But if your tests become complicated then you should understand that something in the controller should be moved level down, e.g. to Service layer etc. You mock services or daos for controllers. You mock daos for services. And if you want to test daos itself, you either mock lower persistence level, or use things like DbUnit...

Something like this... Feel free to elaborate your question
 
Vicky Roy
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rodion Gork wrote:I'm sorry but it is not clear what exactly do you mean. Unit-Testing of server-side classes is nothing different from testing anything else - as you want to test only class itself. For example if you mean to test some MyServlet#doGet method, you instantiate the object, then call doGet passing to it some mocks of "request" and "response" parameters. You set necessary values on "request" and then check that proper data were set on "response".

If your servlet performs whimsical printing to response.outputStream and you feel trouble with testing this, you should come to conclusion that your doGet method has poor architecture. I.e. if you are serving some data to output (e.g. JSON), you should instead prepare this json in separate method, cover it with separate unit-test and then only call this method in your doGet. Unit-test for doGet then should only check that whatever is served by such method, is printed correctly.

If you print the whole JSP-generated response in the servlet - then you should feel that it is not correct to test it with unit-test. You should prefer switching to proper MVC architecture and while covering M and C with unit-tests, Views could be tested with things like Selenium, if necessary.

The same with anything other. E.g. with Spring you will have Controllers which should be tested in similar manner. But if your tests become complicated then you should understand that something in the controller should be moved level down, e.g. to Service layer etc. You mock services or daos for controllers. You mock daos for services. And if you want to test daos itself, you either mock lower persistence level, or use things like DbUnit...

Something like this... Feel free to elaborate your question


Thanks for explaining at this broad level

Actually what I had in my mind is, we have to deploy the app for some components to be active eg. JMS listener. until unless it is deployed in a container it can't listen. Lets say I am developing this application in Eclipse and I want to write a test case for my JMS listener class where it has method for processing the message it receive. How I will deploy it for testing, how it will get message, can we test them in eclipse itself (means in development mode) with some mock server kind of queries.
Hope you got my question.

Thanks,
VickyB
 
Rodion Gork
Ranch Hand
Posts: 47
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How I will deploy it for testing, how it will get message, can we test them in eclipse itself (means in development mode) with some mock server kind of queries.
Hope you got my question.


Yes I got it, but I should tell this is not unit-testing

What you are speaking about is an integration/functional testing (even if you conduct it with the help of tools like JUnit) - because you are not testing units separately.

Usually we use either embedded versions of databases and message queues - or standalone, which are either ever-running on some server, or started with either maven or some CI-tool before the test and shut down after.

However I feel that many of projects I've seen are somewhat wrong in putting too much stress to such kind of testing. The main problem is that such tests are usually significantly slower and require far more efforts to maintain compared to unit-tests. This often leads to situation when tests are not really testing much, but mainly are maintained for the sake of themselves. In some cases they became so more complicated than the code being tested, so that probably such tests should have another tests testing themselves. Another thing is that with unit-tests it is usually possible simply to cover more cases, while integration tests are usually seen to check only few main sequences of user's behavior - e.g. they are rather "smoke"-tests...

People usually say "but such tests allow us to check the whole chain as a single!" - though you may troll them asking further about why really they want to test it as a single instead of carefully testing every part.
 
Vicky Roy
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rodion Gork wrote:

Yes I got it, but I should tell this is not unit-testing



Here I am not agree with you. Does that mean you are in favor of creating a junit test case for every method? If yes, I am not agree. According to me, test case should be created for each flow from the Application entry point. No need to test external services they can be mocked.
 
Marcus Schulz
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Vicky,

I use Arquillian to test the JPA layer or developing queries.
It has maven integration aand even debuggin within in eclipse is possible.
You can test your EJB Service as well.

Maybe it helps.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!