ConfigurationTest is a white box test, not a black box test. The art of TDD includes that we no longer write unit tests as white box tests, we write them as black box tests. We do not want that our unit tests become entangled with low level design decisions. Only things mandated by the use cases should be tested.

That is for multiple reasons. For one thing, the TDD approach wants to prevent what happened with the waterfall design approach - that we end up with lots of code that would actually not be needed. The other thing is that we want our tests to be components in the architecture, following all the principles that our architecture follows in general. Like the SOLID principles, and that includes decoupling. Just as we follow these principles in our architecture to make sure that one change over here doesn't require changes over there in the system, we want that one change over here doesn't require changes over there in the unit tests. It's about reducing maintenance effort and increasing maintainability.

If we find things in our code which are only testable the white box way, this often is an indicator of too complex design, and that our code contains things and complexity which is unnecessary.

A different design would not have Configuration at all, and thus it would not have ConfigurationTest. That shows that Configuration - and ConfigurationTest - are a bit "fishy". ;-)

Of course I'm describing an ideal, there will always be design decisions and certain coupling between test and production code - but we should minimize it and try our best.