This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I have been using a JUnittest case. The problem is that it's pretty tedious: every time I add a new key, I have to change the test case. This has made my team lead think that there's little value in following this approach, even if a recent bug we encountered could have been detected much faster had the test been updated to include the key that had been mangled by a global search and replace. I kind of see his point though. How would you test that a properties file contains all the keys that your program expects?
I don't have any suggestions yet, just a bunch of (hopefully thought-provoking) question...
Originally posted by Junilu Lacar: I have been using a JUnit test case. The problem is that it's pretty tedious: every time I add a new key, I have to change the test case.
What's so tedious about adding a property key to the testcase? Isn't it true for *every* change to the system that you need to adjust the tests?
How would you test that a properties file contains all the keys that your program expects?
What does happen if a property is absent? Why don't your other tests find that malfunction? Will the file get changed after the system is deployed (by the customer/user, for example)?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Dirk: I'm working on a Struts application and the properties file is the ApplicationResources.properties. And yes, the team lead's objection did come from the same feeling of having to maintain something twice. Ilja: Your questions are actually very useful. If I can't find an alternative to the test case, at least I'll have some arguments for using it. A number of things can happen when a properties key goes missing, depending on how the code was written. Unfortunately, our team isn't officially using the TDD approach (although I often hear the team lead saying he wants to use JUnit) and I came up with this test case as a front-line defense. Since I have it though, I don't think my other test cases really have anything specific in them that would help detect a problem in the properties file. The test case has worked well for me and the code I have worked on but other team members seem pretty blas� about writing test cases. So, I am just trying the "Stone Soup" approach and I'm keeping my hopes up that the other JUnit tests that I have will prove themselves valuable later. What I did with the properties test case didn't seem to pique any interest though and that was a bit discouraging so I was just wondering if there was any other approach.