Mocks/fakes and other non-live dependencies

[lukeredpath]

This isn't solely a TCA concern but I'm posting it here as it goes hand in hand with the style of API design and dependency management promoted by TCA - I'm curious to know if and how people are taking steps to avoid that they don't accidentally ship their apps running any kind of non-live dependency.

For example, we may commonly define:

• Mock or other fake implementations of the dependencies we pass around in our environment (e.g. in-memory stores vs database stores, mock API clients)
• Sample data - static instances of our application value types including our state structs, model entities, API responses etc.

Both are generally used in our tests but may also be used in things like SwiftUI previews, or even as stand-ins before we've written the live dependencies while we are developing a new feature.

My preference is to try and keep these mocks/example values close to the thing they are mocking - so if I were breaking these into separate modules (e.g. products in a Swift package) I would generally include them in the same module as the interface. They could just as easily be in your main app target if you're not using a highly modular approach.

I can think of a few safeguards about accidentally shipping code that was using a mock dependency:

1. Wrap all non-release code in a compiler directive, e.g.:

#if DEBUG
extension SomeClient {
  let mock = SomeClient(...)
}
#endif

This is a fairly straightforward approach that we've been using on our current project but it can lead to some issues:

• It assumes that this code will always be used in a DEBUG context. You may only ever run your tests in Debug builds but with this approach you are hardcoding this limitation.
• If you use these in SwiftUI previews, even though Xcode/the compiler does some magic to keep the preview code out of your release builds, the compiler will still fail in Release builds if you don't also wrap your SwiftUI previews in if #DEBUG statements (just like you used to have to in the early betas).
• Its easy to end up accidentally breaking your Release builds if you unintentionally (or intentionally) use one of these mocks (e.g. during a WIP feature) in your code so you are relying on your CI tooling to make sure your Release builds are still compiling, or you need to regularly compile your Release builds manually.

2. Write integration tests for each feature

We lean on TestStore and mock dependencies to drive a lot of our tests and it works great. However there's probably room for at least a couple of integration-style tests that exercise your live dependencies and make sure everything is wired together correctly. Integration style tests tend to be slower and more brittle as they often depend on external resources so its preferable to write fewer of these.

3. Do nothing

This seems like a valid option. Perhaps the risk of mocks slipping into release code in place of live dependencies is so small that its not worth worrying about. The combination of manual testing, some automated testing (integration + UI tests) and code review/pairing practices should be enough to safeguard against this.

Anyone got any views on this or alternative approaches?

[AlexisQapa]

I mostly use 1.

One work around for the limitation is to use another flag than DEBUG you can then build in release or debug mode.

When building for the store you can disable the flag to be sure those are excluded. This is pretty easy to do in Xcode with a custom scheme.

When using SPM you can pass unsafeFlags but I don't think you have an easy way to pass them from Xcode.
You can either duplicate your targets or you define a bool and manually toggle it before starting the build.

One nice thing I found is to map on the targets after they are defined so you can have one place for those thing like:

spmTargets
.map { (target: Target) -> Target in
		var cp: Target = target
		cp.swiftSettings = [
			.unsafeFlags([
				"-driver-time-compilation",
				"-Xfrontend",
				"-debug-time-compilation",
				"-Xfrontend",
				"-debug-time-function-bodies",
				"-Xfrontend",
				"-debug-time-expression-type-checking",
				"-Xfrontend",
				"-warn-long-function-bodies=200",
				"-Xfrontend",
				"-warn-long-expression-type-checking=200",
				keepMocks ? "-DKEEP_MOCKS" : nil
			].compactMap {$0 })
		]
		return cp
	}
)