File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Testing and the fly likes Advice on unit testing and refactoring Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Testing
Bookmark "Advice on unit testing and refactoring" Watch "Advice on unit testing and refactoring" New topic

Advice on unit testing and refactoring

Dave Lush

Joined: Feb 12, 2008
Posts: 2
Hello all,

This is just a quick request for advice really. Our development team is currently trying to evaluate how to implement unit testing in ongoing development as well as possibly adding unit testing to our existing codebase. We have a J2EE app written with flash & remoting plus JSPs on the front end feeding through to a number of stateless session beans and DAOs with an Oracle backend (quite a lot of stored procedures).

We've also looked at and have a fair understanding of stubs, mock objects and in-container testing with Cactus. Unit testing of our external libraries has been successful as its been easy to isolate what we want to test, but we're not sure where to start with adding unit tests into the web and EJB tiers?
I think a key problem we have is that we have a lot of business logic in stored procedures on the database (shared code-base with a legacy app) and therefore our n-tier "design" has often become a case of calling through multiple tiers just to get at a stored procedure.

I appreciate that this is a very broad question with not enough information to answer easily, but is there a strategy we can take for unit testing such a beast? I'm thinking there must be more experienced developers out there that have fallen into a similar trap before? Is it going to require major refactoring and moving business logic from the database into the EJB tier? or would it be worthwile to use database connections in our unit tests and essentially unit test the stored procedures?

Any advice is greatly appreciated
Jeanne Boyarsky
author & internet detective

Joined: May 26, 2003
Posts: 33117

Welcome to JavaRanch!

The first thing to decide is whether you want to write unit tests or integration tests. The difference is that unit tests do not access the database while integration tests do.

I think you would get the most benefit from starting with integration tests because you could test the back end "end to end" and include the stored proc logic.

[OCA 8 book] [Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
You are facing the classical dilemma of legacy code: you need to refactor the code to be able to write unit tests, and you need tests to safely refactor the code.

The basic solution is to apply low risk refactorings that make the code testable (which might even make the design worse on other scales), write tests (which might be more integration than unit tests) and then refactor to a better design.

Micheal Feathers has written a good book on the topic: "Working Effectively With Legacy Code":

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
Dave Lush

Joined: Feb 12, 2008
Posts: 2
Thanks a lot for the quick response. Based on this response, some responses we've had from other forums and initial work we've done over the past couple of days, we've decided to go down the following route (hopefully this might be helpful to anyone else that runs into similar issues).

We're essentially stuck with keeping our stored procedures on the database for the next couple of years. With this in mind we're writing integration tests in the short term. Each integration test will instantiate a java DAO to test stored procedures and the DAO. The setup and teardown for each test then relies on putting a set of test data into the right areas of the database and removing it afterwards. This is obviously a bit time consuming as we need to put both "good" and "bad" data in for the tests. Our DAOs also get their database connections using a factory, which means its been quite simple to switch out the container managed JNDI pools for a physical connection per test.

In the longer term I'd then favour using this library of integration tests to refactor business logic into the EJB tier, allowing us to move toward a mixture of normal unit tests and integration tests.

Just thought I'd put our "solution" up here for anyone with similar problems that stumbles across this thread

Thanks again
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
Do you need a physical JDBC connection per test? As you have a container, you can set up a small connection pool and just reuse the logical connections which the container provides. This will be faster than using physical connections.

SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Consider Paul's rocket mass heater.
subject: Advice on unit testing and refactoring
It's not a secret anymore!