Should configuration be unit tested?

Question

Let me preface by saying I understand opinion-based questions should be avoided, but I was led to StackOverflow after reading this question and so I think in that context it is appropriate.

Should a Unit Test test configuration? Let's say you have a Widget with some magic numbers that if you change the application would be broken (from lack of hardware resources, for example).

class Widget {
  private val parallelism = 32
  private val batchSize = 10

  def someFunction(): Future[Int] = {
    [something that uses the parallelism and batchSize params]
  }
}

Let's say the application broke when someone decided to increase parallelism to 100, causing an outage. So the developer writes a unit test that says:

it should "have parallelism of 16" {
  widgetInstance.parallelism shouldBe 16
}

Does a test like this provide value? Should you be unit testing these configuration items?

According to Wikipedia, the definition of a unit test is as follows:

"Unit tests are typically automated tests written and run by software developers to ensure that a section of an application (known as the "unit") meets its design and behaves as intended."

This definition is not satisfying to me. The unit test arguably tests that a section of an application "behaves as intended." In a similar question, people seem to have a consensus that everything should be unit tested. This is what people said in the other thread:

• "You don't need to test the language constructs, but outside of that, there's really not anything that "shouldn't" be unit tested."
• "You shouldn't write unit tests for other people's code (such as a framework you are using). You should only write tests for your code."
• "If this code is not worth testing, why is it worth having in the first place?"
• "This is a question of cost and benefit, the closer you try to get to 100% the more expensive it will be."

My personal take is that these tests do add value because they point to an architecture issue: configuration should be separate from the application logic. By adding the tests, you highlight this issue and future developers know to refactor it carefully.