• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Advice on unit testing and refactoring

 
Dave Lush
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Cheers
Dave
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34656
365
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave,
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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": http://www.javaranch.com/bunkhouse/Process.jsp#0131177052
 
Dave Lush
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

Thanks again
Dave
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic