Different results in swift-test traits when using different dependency APIs

[ylorn]

Description

Using following code as an example:

@DependencyClient
struct ProblemClient: Sendable {

}

extension ProblemClient: TestDependencyKey {
    static let testValue: ProblemClient = unimplemented("DependencyValue: \(Self.self)", placeholder: .init())
}

extension DependencyValues {
    var problemClient: ProblemClient {
        get {
            self[ProblemClient.self]
        } set {
            self[ProblemClient.self] = newValue
        }
    }
}

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

No response

Actual behavior

No response

Steps to reproduce

When testing with

@Suite(
    .dependency(\.problemClient, .init()),
)
struct ProblemTests {
    @Test func reproduce() async throws {
        @Dependency(\. problemClient) var problemClient
        print(problemClient)
    }
}

error occurs:

Test reproduce() recorded an issue at LoggingClientTests.swift:130:17: Issue recorded
Unimplemented: DependencyValue: ProblemClient …

However, if I changed the test traits:

@Suite(
-    .dependency(\.problemClient, .init()),
+    .dependencies {
+        $0.problemClient = .init()
+    }
)

The test passed, and the original issue no longer occurs.

Why is different API giving different results? Aren't they supposed to function the same?

Dependencies version information

1.10.0

Destination operating system

macOS 26.0.1

Xcode version information

Xcode 26.0.1

Swift Compiler version information

swift-driver version: 1.127.14.1 Apple Swift version 6.2 (swiftlang-6.2.0.19.9 clang-1700.3.19.1)
Target: arm64-apple-macosx26.0

[mbrandonw]

Hi @ylorn, .dependency and .dependencies are roughly equivalent, but Swift does have different behavior between setting a field on a value directly and setting a field through a key path in a generic context. You can see this here:

@Test func foo() {
  struct S {
    var x: Int {
      get { fatalError() }
      set { }
    }
  }

  var s = S()
  s.x = 42
  set(&s, keyPath: \.x, value: 44)  // 💥
}

func set<R, V>(_ root: inout R, keyPath: WritableKeyPath<R, V>, value: V) {
  root[keyPath: keyPath] = value
}

The getter is called when setting x through the key path, and that is why your unimplemented is being called. I don't think there is really anything we can do about this since it's Swift behavior.

However, I also don't think what you are doing in this code snippet is necessary. The unimplemented function is more for mocking endpoints of a dependency with an implementation that fails tests when invoked unless overridden. It's not made for "unimplementing" the whole dependency itself. And on top of that, the @DependencyClient does all of this for you automatically. Here is an example:

@DependencyClient
struct ProblemClient: Sendable {
  var invoke: @Sendable () -> Void
}

extension ProblemClient: TestDependencyKey {
  static let testValue = ProblemClient()
}

struct ProblemTests {
  @Test func reproduce() async throws {
    @Dependency(ProblemClient.self) var problemClient
    problemClient.invoke()  
    // 🛑 Issue recorded: Unimplemented: 'ProblemClient.invoke'
  }
}

The macro created an initializer for ProblemClient that takes no arguments, and each closure is filled in with an "unimplemented" version.

So I believe the library is worked as intended. Since this isn't an issue with the library I am going to convert it to a discussion. Please feel free to continue the conversation over there!

[ylorn]

Thanks for the explanation, would be great if this is mentioned somewhere like in the gotchas about the difference between keypaths and closures. Pulling my hair out find a workaround. 😂

As for the @DependencyClient macro:

However, I also don't think what you are doing in this code snippet is necessary. The unimplemented function is more for mocking endpoints of a dependency with an implementation that fails tests when invoked unless overridden. It's not made for "unimplementing" the whole dependency itself. And on top of that, the @DependencyClient does all of this for you automatically.

I believe this true only if the client struct has at least one closure property, as for those that does not have such properties, testValue needs to be manually implemented.

[mbrandonw]

I believe this true only if the client struct has at least one closure property, as for those that does not have such properties, testValue needs to be manually implemented.

Hi @ylorn, what is the use case for a dependency with no endpoints for which you want to fail the test by the mere act of "touching" the dependency _ = client? This just doesn't seem useful to us, and so we aren't going out of way to support it.

[ylorn]

My case is something like this:

https://github.com/pointfreeco/swift-sharing/blob/d0c8ef8d889a25c38f2d47c42f2064a7b7d0db08/Examples/FirebaseDemo/RemoteConfigKey.swift#L96

Mainly want to tap into the dependency system without declaring a default value which the Sharing package strictly requires.