Should we test the values of a Config File (or a DI container)?

general question. Today I had a talk with some colleagues concerning what we should test and what we should not test in a (Web) app. People were very strong on either side of the fence when it came to configuration values/DI containers. Basically the two camps were as follows:

Camp 1 - DO NOT TEST INFRASTRUCTURE OR SUCH THINGS:

• There is no point in checking the value in a configuration file, such as a connection string since a deployment agent (like Octapus), can override it and break CI.
• Furthermore, you can write an acceptance test. If a page loads then, duh, the connection string is working fine.
• Same with integration tests (UPDATE/DELETE) etc on a DB. If these pass, the connection string works fine.
• No need to make sure that a DI container is actually registering everything. An acceptance test will tell you (See above)

Camp 2 - EVERYTHING THAT CAN BE TESTED SHOULD BE TESTED. IF THERE IS A CHANGE IN AN APP, THEN A TEST SHOULD NOTIFY YOU OF THAT CHANGE NO MATTER HOW SMALL:

• We should check that we have stored the correction connection string in a config file. If someone changes that connection string, a test should fail and someone should be aware of it (useful if both connection strings point to the same DB, but one of them is outdated and/or readonly).
• We should create a wrapper around such things as DIs and make SURE we are calling them during our initialize method. As such, we would not be testing the DI itself but the call to it.
• We should NOT rely on acceptance/integration tests that test different things to verify a side effect (e.g. the fact that an UPDATE is working correctly, does not mean that it should also even side-ways test the fact that a connection string is working as well)
• Follow TDD: the very moment we introduce a connection string, we should write code that tests it (integration or unit). If not then we would have to rely on a test further down the line to side-effect test it.

And so on. The argument went on for quite a while. Myself I feel more partial to Camp 2. I like to test everything, and I feel that everything we introduce should have a test around it (one way or another).

But I can also see the argument of Camp 1 - some consider things as connectionstrings, route configurations, or DIs pure infrastructure that needs not be tested.

What do you guys thing?