• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Unit testing - simulating a JVM restart

 
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
Thoughts?

 
reply
    Bookmark Topic Watch Topic
  • New Topic