How to inject a dependency in an Environment's dependency, in such way that it is testable?

[ghost]

Looking at the Search Demo example, I find this awesome way to replace an implementation:

store.assert(
    .environment {
        $0.weatherClient.searchLocation = { _ in Effect(value: mockLocations) }
    },
    // ...
)

In the weatherClient interface, the searchLocation variable is just replaced with a suitable mock for testing. This is great!

The thing to keep notice, in this example, is that the WeatherClient doesn't have dependencies itself. It uses URLSession in its live implementation, so URLSession is accessed globally, and not injected into the client.

Like this:

extension WeatherClient {
  static let live = WeatherClient(
    searchLocation: { query in
     // ...
      return URLSession.shared.dataTaskPublisher(for: components.url!)
    // ...
    },
  // ...
}

Now, let's say I have this:

struct WeatherClient {
   var entityClient: () -> EntityClient<LocationModel>
   var searchLocation: (AnyHashable, String) -> Effect<[Location], Failure>

   struct Failure: Error, Equatable {}

}

Where searchLocation needs to access the entityClient function, to perform a search.

So the question is, how can I access the entityClient in a Live implementation? Or how can I inject it there?

If I try to replicate the solution from the Search Demo, I get a solution for testing just fine. Just replace the searchLocation function. But in my live implementation I need to also get to my entityClient. And I can't do it this way.

I can't access entityClient from the scope of the searchLocation function.

I can't so this:

weatherClient.searchLocation = { id, search in
  entityClient().search(search) // Doesn't work, as entityClient is out of scope
}

There are 2 solutions that I considered so far:

Similar to using a global URLSession, I could expose a global instance of a CoreDataStack in such way that I could do this anywhere:

let some: EntityClient<LocationModel> = CoreDataStack.live.entityClient()

I could also, instead of using a pure struct that defines the interface by itself, provide a Protocol like WeatherClientProtocol and have both a Live:

struct LiveWeatherClient: WeatherClientProtocol {
   var entityClient: EntityClient<LocationModel>
   
   func searchLocation(id: AnyHashable, search: String) -> Effect<[Location], Failure> {
       // ...
   }

    struct Failure: Error, Equatable {}
}

And mock versions:

struct MockWeatherClient: WeatherClientProtocol {
    // ...
}

Has someone thought about this and come up with a solution other than these 2?

I'm not yet fully comfortable with the idea of exposing a CoreDataStack.live to all my 20+ components, and while the Protocol adoption might work, it looks clean in this more short example, but in reality, it has a large amount of functions behind it, and require a large amount of boiler plate for each test to just implement 1 function and then a ton of fatalError("not implemented") on all functions.

Am I making this more complicated than it should? 🤔 Apologies for the confusing Title! 🙏

Thanks!

[mbrandonw]

Hi @DiCoDa,

I've got a couple of comments and questions for you:

• You say that you'd like to inject a URLSession into WeatherClient to make it "testable", but is there some way in which the current WeatherClient is not testable? And does injecting a URLSession into the client somehow unlock more testing abilities that are not currently possible?

• If you really do need a URLSession injected in WeatherClient, then it can still be done by making live a static function instead of a static let, and passing arguments to the function:

  extension WeatherClient {
    static func live(session: URLSession = .shared) -> Self {
      Self(
        searchLocation: { id, query in 
          // use URLSession in here to do search
        }
      )
    }
  }

• If you dependency needs some other data provide in order for it to do its job, such as a core data stack, then you can also pass that into the .live() dependency as an argument, just as URLSession was:

  extension WeatherClient {
    static func live(coreData: EntityClient) -> Self {
      Self(
        searchLocation: { id, query in 
          // use EntityClient in here to do search
        }
      )
    }
  }

Does any of that help out?

[ghost]

Dear @mbrandonw

It's not that the WeatherClient isn't testable, as it is, wonderfully so. It's that I wasn't seeing how I could get to my entityClient, in my live implementation, by 1. not using a Global instance, or 2. not imposing a full protocol conformance per test and then per entity.

Now that I see this, using a static function instead of a let does work:

extension WeatherClient {
  static func live(coreData: EntityClient) -> Self {
    Self(
      searchLocation: { id, query in 
        // use EntityClient in here to do search
      }
    )
  }
}

It seems so simple now, but I couldn't find my way to it.

That really helps, thank you so much! 🙏

[mbrandonw]

Great to hear, glad it helped!

[swasta]

Hi @mbrandonw! I stumbled upon this discussion and your first comment got me a little confused. I would be so much grateful if you could explain it in more detail.

Trying TCA approach in my pet project I had to decide how to provide dependencies to my clients/services/managers. The case studies didn't help me much, because typically all the clients there are moderately simple. Everything they need to access they access directly, I mean URLSession, AVAudioSession. So my questions are:

1. Do you suggest that there's no point injecting system entities such as URLSession? Is that because then we should at least wrap the session in a protocol so that to test expected endpoints were called by the WeatherClient?
2. What if the live implementation of the Weather Client is much more complex and hence requires live versions of other clients? Like Network client or Persistence Client. Does it then justify the injection of these clients via static func? For example, testing Weather Client we probably should make sure that it interacts with the mocked version of Network Client as expected.
3. I couldn't find tests on any of the live implementations of the clients. Is that a deliberate decision? Would you specifically test the live implementation of the client if it was complex enough?

Thanks for your time!

[siejkowski]

While waiting for @mbrandonw answers, I'll just share an other approach I've been doubling with in my own projects.

You can keep the clients very simple by making them just thin wrappers over the dependency API. All the business logic is moved out of the client and to the TCA land. It basically reduces any need for testing the live client implementation, because testing it is equivalent to testing other party code.

It means I have a few TCA packs (meaning State + Action + Environment + Reducer) in my projects that are never used in the views. They are only responsible for performing the logic that I've extracted from the client. They basically are services written with TCA.

Not sure it is a "better approach" then using the usual testing style for clients (injecting dependencies to client under protocol and mocking them so that the live client can be tested), but it enables you to test the model logic.

[ghost]

Hi @swasta

Would it be ok if I step in?

1. Do you suggest that there's no point injecting system entities such as URLSession? Is that because then we should at least wrap the session in a protocol so that to test expected endpoints were called by the WeatherClient?

You can certainly inject a dependency, as suggested by @mbrandonw. See how this live implementation injects an EntityClient . This is close to a use case of mine, and my entityClient instance would be used in searchLocation to query a managed object context of CoreData.

extension WeatherClient {
  static func live(entityClient: EntityClient) -> Self {
    Self(
      searchLocation: { id, query in 
        // use EntityClient in here to do search
      }
    )
  }
}

I would suggest you keep tests of your dependencies out of your components. Let's say you built, a URLSessionlike framework. When you inject it, it should have already been tested in its own package/framework. To elaborate a bit more, have a look at the tests provided be the Search Example:

store.assert(
  .environment {
    $0.weatherClient.searchLocation = { _ in Effect(value: mockLocations) }
  },
  .send(.searchQueryChanged("S")) {
    $0.searchQuery = "S"
  },
  .do { self.scheduler.advance(by: 0.3) },
  .receive(.locationsResponse(.success(mockLocations))) {
    $0.locations = mockLocations
  },
  .send(.searchQueryChanged("")) {
    $0.locations = []
    $0.searchQuery = ""
  }
)

See how it's not testing the weather client. That's because it won't matter if it's a mock or live implementation:

struct WeatherClient {
  var searchLocation: (String) -> Effect<[Location], Failure>
  var weather: (Int) -> Effect<LocationWeather, Failure>

  struct Failure: Error, Equatable {}
}

What matters here is the interface provided above by the WeatherClient, because it restricts what it can output in such a way that you can't provide more or less based on using a mock or live version. The searchLocation function will always have a (String) param and return an Effect<[Location], Failure>, be it live or mock.

What we're testing in the search example, and all other examples, is if if your reducer if mutating state as it should.

2. What if the live implementation of the Weather Client is much more complex and hence requires live versions of other clients? Like Network client or Persistence Client. Does it then justify the injection of these clients via static func? For example, testing Weather Client we probably should make sure that it interacts with the mocked version of Network Client as expected.

If you consider the answer to 1. you'll see that it won't matter how complex or how many dependencies a dependency can have. If you have a dependency large enough, like the example I gave for CoreData, by the time you import and use it in your component, it should have already been tested on it's own. Again, because we're not testing your dependencies, we're testing our reducers and using an interface provided by our WeatherClient.

To answer your question, yes, it does justify the injection of clients via a static func. Just like the example that @mbrandonw helped me with. In fact, it feels like the "only" reasonable way to do it.

3. I couldn't find tests on any of the live implementations of the clients. Is that a deliberate decision? Would you specifically test the live implementation of the client if it was complex enough?

I'm hitting the same key, but once more, you're testing using an interface already, provided by the WeatherClient, both the live and mock can only return this:

var searchLocation: (String) -> Effect<[Location], Failure>
var weather: (Int) -> Effect<LocationWeather, Failure>

So this live implementation:

extension WeatherClient {
  static func live(entityClient: EntityClient) -> Self {
    Self(
      searchLocation: { id, query in 
        entityClient(id: id, query: query)
          .map { $0.map(Item.init(model:)) }
          .mapError { _ in Failure() }
          .eraseToEffect()
      }
    )
  }
}

Is the same as this test against a mock:

store.assert(
   .environment({ (system) in
      system.weatherClient.searchLocation = { _ in Effect(value: mocks) }
   }),
   .send(.onLoad),
   .receive(SomeAction.fetch),
   .receive(SomeAction.received(.success(mocks))) {
      $0.results = mocks
   }
)

But if you're asking about testing the dependency itself, then you can certainly do so. Again, the EntityClient example is part of a large framework with a CoreDataStack and lives in its own Target/Framework, with its own completely independent tests.

Does this help?

[swasta]

Thanks @siejkowski and @DiCoDa for the valuable input! Even though writing services as TCA packs sounds a bit too exotic to me, injecting dependencies, whose live versions were tested in their own frameworks, really makes sense. What I was confused about is Brandon's statement that injecting URLSession doesn't make live version of WeatherClient more testable. Because I still think it does, at least if it's wrapped into some protocol and if by testability we mean testing the client in complete isolation from any TCA reducers.
I wish we could study isowords source code to see how dependencies are tested there. Maybe someday🙂