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

Unit testing - simulating a JVM restart

Jelle Klap

Joined: Mar 10, 2008
Posts: 1951

I like test driven development, but I'm also in favor of taking a pragmatic approach - meaning I usually cheat my way thru the test-code-refactor cycle
Yesterday though, I started work on a tiny little project (on my own time) and decided to take a more strict approach and stick to it - just for the heck of it. That worked pretty well until I ran into the persistence hurdle. Now just to clarify, I know how I can effectively test a persistence layer, and that's not the problem. The "problem" is that I'm trying to test drive the persistent behaviour of the data in the application; the "need" for a persistence layer so to speak. Just a quick side note: I realize that test driving out the need for persistent storage of application data is taking a good thing way too far - I just wanted to see if it could be done

Starting out I used instance fields to get the first tests to pass. While working my way thru the TDD grind and in persuit of the green bar, I had to switch to static fields. After which I hit a ceiling of sorts. Where to go from there - beyond static? More to the point, how do I test drive the need for a storage mechanism beyond static fileds? The file system seemed like an obvious candidate, but how do I test drive that switchover? How do I write a unit test that checks that newly generated data survives a JVM restart? The only thing that I could come up with was to preclude static fields as a viable storage option by writing a custom ClassLoader that loads a completely seperate copy of the application's class hierarchy.

Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
I agree. Here's the link:
subject: Unit testing - simulating a JVM restart
It's not a secret anymore!