4

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.

Thanks!

2 Answers 2

5

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

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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