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.
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.