I’m not going to recommend you read all the books you can get your hands on, though you could if you wanted to. These are the tips they don’t teach you in books or in school. From deleting code and refusing to comment, through to deliberately throwing exceptions, these tidbits of experience will make you a faster and smarter developer. And that’s what you want, right? Read on ..
In most server-side applications there will be a requirement to persist your data to some storage layer. Spring provides a neat abstraction in the form of the JdbcTemplate to achieve this, and in combination with a Spring-injected DataSource you can easily switch your data source between testing and production databases. Unfortunately the recommended and well-publicised test strategies for *integration* testing of your applications involving Apache Derby, HSQL (HSQLDB), and MySQL don’t enable rapid-fire *unit* testing of your data access code, since they require a real database to be at some known location on your disk or on a server (or in the case of HSQL don’t completely support all of the JDBC-3.0 spec).
Today, I’ll take you through combining some free components that enable you to run unit tests on your JDBC data access layer in a completely in-memory fashion, which allows you to more easily run regular complete and predictable tests of your data access layer and get consistent results. In fact, this solution isn’t limited to just Spring applications; any JDBC code can be tested like this!
I was working with Lingo (a RPC over JMS mechanism for Spring) last week and we uncovered an issue in which Lingo threads were not closing properly. The problem was uncovered since our JUnit tests were running fine, but any application which used a main() method had to call System.exit() to finish, which is ugly. Additionally, our Tomcat server application would not close, there were a number of threads left around even after the Spring context and ActiveMQ broker had been taken down.
With a little effort I isolated the code to a mistake in the Lingo MultiplexingRequestor. The MultiplexingRequestor uses threadpool internally, and the close() method is not overridden, which causes the threadpool (and attached threads) to linger indefinitely.
The bug and solution code has been filed as LINGO-44. To use this, simply copy the MultiplexingRequestor to your local project and ensure the updated code comes *ahead* of lingo-1.3.jar in your classpath.
You are currently browsing the archives for the java category.