aspose file tools*
The moose likes Testing and the fly likes Testing web app business logic Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » Testing
Bookmark "Testing web app business logic" Watch "Testing web app business logic" New topic
Author

Testing web app business logic

Samuel Cox
Ranch Hand

Joined: Nov 16, 2004
Posts: 96

Hello,

My boss has given me the charge of developing tests for our web application (Tomcat + JSP + struts + business logic + DB).

I would like to start with our business layer objects, which are populated from the database.

I have seen MockObjects and Cactus mentioned and read briefly about them. They seem pretty in depth, and I'd rather not delve further into them if there is a convenient way to unit test my objects with normal JUnit tests.

Anyhow, is MockObjects/Cactus my best bet or is there a way to construct an object in a unit test where the object is populated from a database (db connection handled by tomcat)?

Any thoughts or links are appreciated.
Ken Loh
Ranch Hand

Joined: Feb 16, 2005
Posts: 190
I'm currently using JUnit, CactusStruts, MockEJB, HttpUnit and maybe one or two other test frameworks.

Cactus is quite easy to be applied. The problem probably lies in distilling the information from Cactus websites. It took me only a day to get my Cactus up and running for my usual test cases. Of course, it's an ongoing learning experience that might have no end. After 3 months, I still can't say that I know Cactus very well. However, I'm satisfied with the test cases that it allows me to build and run.

While Cactus is often referred as an integrated-test framework, it is sufficient for me to use it for unit test. I'm able to test all my business methods for both remote and local EJBs. With CactusStruts, I'm able to test my Struts action classes as well.

I also use HttpUnit to test how my web pages as seen through the browser. I think you could call this an acceptance test. Took me a day to get it up and running after reading about it for couple of days. For my case, it's best to experiment while reading about it from websites as the texts could be quite confusing and takes too much time.

I use MockRunner where I don't know how I could make use Cactus like testing MDB.

To show you my learning route, please see below:

* includes waiting time for reply to posting in MockEJB home after encountering problem.

Happy testing!
[ June 20, 2005: Message edited by: Ken Loh ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Ideally, your business objects don't know anything about the DB. Whenever they need some persistence service, they get it through an abstract interface, for example a DAO.

So, for the tests, you only need a test implementation of the DAO (a mock) that provides test data to the business object.

Does that help?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Samuel Cox
Ranch Hand

Joined: Nov 16, 2004
Posts: 96

First, Ken thanks for describing your process. I think that I'm going to start by researching Catcus.

Ilja, we are currently moving persistence layer to exist behind DAOs. However, I was still hoping that I could somehow test my business objects by having them instantiated through DAOs backed by the actual database.

Thanks for the tips.
[ June 20, 2005: Message edited by: Samuel Cox ]
Ken Loh
Ranch Hand

Joined: Feb 16, 2005
Posts: 190
While waiting for Ilja to reply, please allow me to be a busybody for a moment and to contribute my 2 cents' worth.

I think what Ilja meant was information hiding of the DB, and not discard the use of it. The DAO encapsulates the underlying DB layer, easing the way a user manipulates the data as he doesn't need to know about the nature of the DB underneath. All he sees is the DAO layer.

Therefore, you'd need only to test the DAO without worrying about what goes behind.

Originally posted by Samuel Cox:

Ilja, we are currently moving persistence layer to exist behind DAOs. However, I was still hoping that I could somehow test my business objects by having them instantiated through DAOs backed by the actual database.

Samuel Cox
Ranch Hand

Joined: Nov 16, 2004
Posts: 96

Yes, I understand the principle of separation. It is the creation of a mock that concerns me. Our objects are fairly large, and I was hoping to instantiate them from the DB for testing purposes.

Anywho, thanks for the tips.
Yan Lee
Ranch Hand

Joined: Sep 15, 2003
Posts: 94
Hi Samuel,

I was in a similar situation a few months ago and was not able to find the answer in Cactus. I needed an in-container testing framework that would help me test EJB, business logic , web services, POJOs and messaging components in my application. Also I wanted to externalize the test data from the test classes.

Finally, I wrote my framework and I am actively using it to test ejb's business logic, persistence and web services.

I have put it on sourceforge for others who might have similar needs. You can check it out at http://www.sourceforge.net/projects/marigold

There is detailed documentation on how to use the framework. Feel free to contact me (email id is on sf) if you decide on using it and have any doubts.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Samuel Cox:
Our objects are fairly large, and I was hoping to instantiate them from the DB for testing purposes.


I don't think that's a good long term strategy - having many of your tests depend on the database. I'd fear that it results in a lot of pain during maintenance.

If I were you, I'd first try to break my objects down into smaller ones.

You might also want to look out for the Object Mother pattern.
Samuel Cox
Ranch Hand

Joined: Nov 16, 2004
Posts: 96

Ilja, point well taken. We definitely need to break a few of our larger objects up.

code poet, I'll try to take a look at your project.

Thanks to everyone.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Testing web app business logic