This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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?
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.
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
Joined: Feb 12, 2008
Hi, 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
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.