Allow apps to supply custom testValue for built-in dependencies (e.g. Calendar, TimeZone)

[chris-jarvi]

We rely on Calendar and TimeZone from DependencyValues in many features. In tests we need deterministic values (e.g. a fixed time zone like EST and a consistent calendar) for snapshot stability and date logic. Because CalendarKey and TimeZoneKey are private and only provide liveValue, we have to override calendar and timeZone in every @suite (or test) that touches them—often the same three lines repeated many times:

.dependency(\.calendar, .autoupdatingCurrent),
.dependency(\.calendar.timeZone, try #require(TimeZone(abbreviation: "EST"))),
.dependency(\.timeZone, try #require(TimeZone(abbreviation: "EST"))),

Proposal: Support a way for the app to supply a default testValue for these (and optionally other) built-in dependencies, so tests get a deterministic calendar/time zone by default and only override when a specific test needs different values.

Possible approaches we had in mind (open to better ideas):

• Option A: A one-time “test defaults” registration (e.g. in test setup or via a trait) that merges into the dependency context for tests, e.g. DependencyValues.registerTestDefaults { $0.calendar = myTestCalendar; $0.timeZone = myTestTimeZone }, so any test that doesn’t override gets these values instead of hitting reportIssue.

• Option B: Make the keys for built-in dependencies (e.g. CalendarKey, TimeZoneKey) or their testValue overridable by the app (e.g. by making the key type or a “test default” hook public and document how to set a custom test default for Calendar/TimeZone).

Either way, the goal is to avoid repeating the same calendar/time zone overrides in every suite while keeping the ability to override per test when needed.

[mbrandonw]

Hi @chris-jarvi,

we have to override calendar and timeZone in every @suite (or test) that touches them—often the same three lines repeated many times:

Are you aware that you can make a base test suite so that you only have to do this work a single time:

@Suite(.dependencies { … })
struct BaseSuite {}

extension BaseSuite {
  struct FeatureTests {
    // This test has dependencies overridden.
  }
}

That would be the simplest and least leaky way to do what you want. Any escape hatch we open up to make it possible to override dependencies in other ways only makes the library more complex and easy for us to get something wrong.

Possible approaches we had in mind (open to better ideas):

For each of these options I'm not sure how it actually solves your problem. Even if we opened up a kind of registerTestDefaults or "hook", wouldn't you still have to do that in each of your suites?

[Younglilly4]

Hi @chris-jarvi,

we have to override calendar and timeZone in every @suite (or test) that touches them—often the same three lines repeated many times:

Are you aware that you can make a base test suite so that you only have to do this work a single time:

@Suite(.dependencies { … })
struct BaseSuite {}

extension BaseSuite {
  struct FeatureTests {
    // This test has dependencies overridden.
  }
}

That would be the simplest and least leaky way to do what you want. Any escape hatch we open up to make it possible to override dependencies in other ways only makes the library more complex and easy for us to get something wrong.

Possible approaches we had in mind (open to better ideas):

For each of these options I'm not sure how it actually solves your problem. Even if we opened up a kind of registerTestDefaults or "hook", wouldn't you still have to do that in each of your suites?

How can I do that

[mbrandonw]

I believe I explained things above. What about the above doesn’t make sense? Also we have docs on this topic.