Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For example, there are some key-value configuration in .properties file. Such like someFeatureEnable=true. It must be bool type value which will be parsed by framework, in my case it's typical Java Spring configuration. Spring will handle the configuration and throw Exception when users set someFeatureEnable=123.

My question is: if there many properties in .properties file, Is it worth testing them one by one? It's quite troublesome and low priority. The .properties file is always configured by tech administrator stuff. Limited chances that they will mess up the configuration.


share|improve this question
up vote 5 down vote accepted

If a property is trivial (i.e. it merely returns a value), no, I don't write a unit test for it.

Instead, I rely on the unit tests that prove that the framework parser works, and unit tests that prove that the code that depends on the property settings works.

If there is a problem reading the properties (because one is misspelled, perhaps), it will show up somewhere else in the testing chain (most likely in the integration tests).

share|improve this answer

I beleive that you should write tests for the accepted properties that you've defined (i.e. The enum of properties that are valid). However, as these can be changed on the fly at runtime a far mor eimportant test is an integration style test (perhaps unit depending on your design) that tests your property parsing code and how it deals with outright bad or perhaps invalid input.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.