Configuration files in source control are pretty much equivalent to constants in a programming language.
And the distinctive thing about constants, at least in most programming languages, is that if you treat them as the unit under test, they literally cannot have any internal bugs.
final static double PI = 4.2;
has no locally detectable bugs. It just has a lot of 'potential integration issues'...
You can write a test for it as:
assertThat(PI, is(closeTo(4.2, epsilon));
and that not only won't find the problem, but will fail when somone fixes it.
If you work on a code base in this style, then every change you make will fail a test. Which is more or less equivalent to not having any tests; it's practically like having two copies of the source code in git and requiring them to be the same to 'prevent unintentional modifications'.
Either you have to read and review the code, or test at a larger level. For example noting that circles using PI are wonky.
In your case, this would mean testing that:
- the default behavior is correct
- changing the config value changes the behavior