Is there a way to define a default testValue only in the Test target

[flopshot]

I have a dependency

// Opt-In for @Dependency(\.sessionState)
public extension DependencyValues {
  var sessionState: SessionState {
    get { self[SessionStateKey.self]! }
    set { self[SessionStateKey.self] = newValue }
  }
}

public enum SessionStateKey: DependencyKey {
    public static let liveValue = appContainer.resolve(SessionState.self)
}

but I don't want to define the testValue in the app target. I want to define it in the test target

// in TEST file in TEST target
public extension SessionStateKey {
    static let testValue: SessionState? = SessionStateMock()
}

Doing the above, I still get an error

@dependency(.sessionState) has no test implementation

Is this not possible? Do I have to provide default test values in production code?

[mbrandonw]

Is this not possible?

No, this is not possible. This is just how Swift protocols work. You cannot take a protocol hierarchy P1: P2 and conform a type to P1 in module M1 and conform to P2 in M2 unless M1 depends on M2. In your situation this would mean that the app target needs to depend on the test target, which of course cannot be done.

Do I have to provide default test values in production code?

Yes, you have to define a default test value in production code, but in practice this is not a big deal. We highly recommend that the default testValue just be an implementation that does nothing in its endpoints and triggers an XCTFail. In fact, if you use our @DependencyClient macro, this conformance will be defined for you automatically.

If you still do not want to define testValue in your app code, then you can just leave it off. What will happen is if \.sessionState is accessed in a test then you will get a test failure like you posted above, and you will be forced to override it in tests.

[flopshot]

Yes, you have to define a default test value in production code

My manager won't allow our production code base to have test implementation.

If you still do not want to define testValue in your app code, then you can just leave it off... and you will be forced to override it in tests.

There are a LOT of tests that I have to do that in now.
In our legacy code base, we would be doing this everywhere, while we migrate to stop using the service locator pattern.
I don't pretend to know your resons for this, but it would be nice to just make these test failures warnings, allowing us to migrate to this pattern incrementally

[mbrandonw]

I don't pretend to know your resons for this, but it would be nice to just make these test failures warnings, allowing us to migrate to this pattern incrementally

I'm not sure I understand how a warning helps. If the test did not fail then you would be using a live dependency in your test, which is both dangerous (e.g. tracking analytics accidentally) and typically makes it impossible to actually assert on the data in your feature since it came from the outside world.

Can you explain why it would preferable for the test suite to not fail in the case of using a live dependency in your test suite?

[flopshot]

I don't disagree with anything you're saying, but at the moment our terrible code base has Global singleton's that dispatch all over the place. Our Account presenter somehow dispatches out to the Account event bus which I have to deal with while I migrate to our new view model implementation that just needs to hook into it.

Needless to say, it would be nice to just provide a default mock for SessionState in test code only, without having to define it for every test

[mbrandonw]

Hi @flopshot, I do sympathize with having a difficult code base to work in, but on the flip side, if we do offer the tools you are asking for we are only making it possible for others to create messy code bases too. The whole point of this library is to help people wrangle in the complexity of dependencies, and so we must be steadfast in not allowing small hacks enter the library just to fix a few peculiar situations people come across.

Another alternative for you to consider is to have the testValue be the live value:

public enum SessionStateKey: DependencyKey {
  public static let liveValue = appContainer.resolve(SessionState.self)
  public static let testValue = liveValue
}

This will no longer produce failures in tests, but it will mean using live dependencies in the test. That is quite dangerous to do, but if it unblocks you temporarily then you could try it.

[flopshot]

Believe you me, if I could just define SessionStateMock in the app target I would. But sadly, I can't. Thanks for the help