CODEWITHSUNDEEP
javatestingspring-bootyamlintegration-testing
Gaurav Abbi
Gaurav Abbi

Reputation: 645

Unit/integration tests that verify the properties or configurations

Does it make sense to write unit/integration tests that verify the properties or configurations, since any medium to highly complex applications include a lot of configurations (via YAML or properties files)?

Many of these configurations derive the run time behaviour even if they are used by the underlying libraries or frameworks. Would it be a sensible idea to verify that the configurations are correctly used at runtime?

One pro-argument is since there is no compiler safety, we need to somehow verify if the configurations are dictating the behaviour correctly.

The con argument is, are we verifying the underlying frameworks implementation?

Testing just the configuration file might not be enough as it does not guarantee if the configuration will be correctly employed at runtime (there could be typos or other similar mistakes).

Upvotes: 3

Views: 186

Answers (2)

David Leppik
David Leppik

Reputation: 3304

No. Unit tests will tell you what works in the test harness, which is—and should be—different from what is in production.

You hit the nail on the head when you said you want to verify the configuration. Testing and verification are two entirely different things. If you have a way to verify the runtime configuration in production, it will also help you diagnose runtime misbehavior.

There are lots of ways to verify the runtime configuration. The simplest and best is logging (e.g. "2016-09-24 10:13:00 connecting to http://my-configured-server.example.com to get user token"). Don't just dump the configuration to the log file-- that's not end-to-end verification-- sprinkle configuration details into log messages.

Configuration issues are often all-or-nothing; if you don't get the configuration just right, nothing happens and you don't know why. (This is especially true with functional programming.) Logging can tell you not only what the configuration is, but at what moment the configuration fails.

There are other clever ways to sprinkle configuration details into the runtime. For example, attaching verbose runtime details to error messages, especially email where you have more room than in logs. Or a debug mode where hovering over a UI element tells you the class and other facts about that element.

Integration tests (the components work when plugged together) and smoke tests (some complete configuration does something right) can be important-- I would say necessary if you deploy without manual testing-- but they are no substitute for runtime verification.

Upvotes: 3

ekostadinov
ekostadinov

Reputation: 6940

This is pretty reasonable IMHO, especially when talking ever growing virtualization. In one of the previous projects I was involved - a mSOA platform, which supported (back then) hundreds of web sites with ease, we found out that most of the issues were due to exactly

configurations are correctly used at runtime

The Orchard recepies were messed up a lot of the the times, as well. So a point for Docker containers. It is pretty much straightforward to test the infrastructure and its configuration your product/service is using. I've used successfully serverspec.

Upvotes: 1

Related Questions