Suddenly Getting Unimplemented: ContinuousClock.now On Every Test

[david-hosier]

I've been working on a bunch of tests for my TCA-based app the last couple weeks. When I stepped away from my desk last Friday, I swear my tests were working fine. Then I sit down at my desk this morning, and everything is failing with "Unimplemented: ContinuousClock.now" error. In order to eliminate any changes that I may have forgotten about, I worked up the simplest of examples that basically does nothing, and I still get this error when trying to run the test. See below for my simple example:

import ComposableArchitecture
import XCTest

@MainActor
final class DummyTests: XCTestCase {

	func testDummy() async {
		let store = TestStore(
			initialState: DummyReducer.State(),
			reducer: DummyReducer())
		
		await store.send(.dummy)
	}

}

struct DummyReducer: ReducerProtocol {
	struct State: Equatable {}
	
	enum Action: Equatable {
		case dummy
	}
	
	func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
		switch action {
		case .dummy:
			return .none
		}
	}
}

You can see that I do not even have a dependency on continuousClock in this example, yet I get the "Unimplemented: ContinuousClock.now" listed a bunch of times on my test function (i.e. the testDummy() line is highlighted in red and the error is listed six times...and it seems the number of times the error is listed changes each time I run the same test), and the test fails. Even if I override the continuousClock dependency with ImmediateClock, I get the same error.

I am on the latest release of composable architecture 0.49.2, and XCode is showing v0.1.3 for swift-dependencies and v0.2.0 for swift-clocks libraries.

Is this only happening to me? Did Gremlins get into my laptop over the weekend? I'm hoping someone might have some clues for me.

[mbrandonw]

Hi @david-hosier, this most likely has to do with the fact that when tests run in an app target (as opposed to framework or SPM library) the simulator actually starts up and executes your application's code. So, that code will think it's in a test context and access non-overridden dependencies, causing the failures.

Honestly, it's a huge gotcha that an application is running in the background, executing real life code. It means the simulator could be firing off network requests, tracking analytics events, and more, all without you knowing. TCA just happens to make this gotcha very in-your-face.

The best solution is to extract out basically all code from the app target into frameworks/libraries, and then you can run tests on those targets more easily. However, that's a big change, so another idea is to wrap the entry point of your application in a if ! _XCTIsTesting check (that's a helper from our XCTestDynamicOverlay library), which prevents any of your code from running in the simulator during tests.

This issue has come up enough times (see here) that we should probably have documentation on it. I will try to write up something soon.

[david-hosier]

Ok, based on this, I think I might understand what's happening. At the end of the day on Friday, I did finish reimplementing some timer actions in my root reducer. So even though I'm not testing the app, I think you're saying the app is running in the background. And the timers are spinning up and firing in my app now when the tests are running, thus triggering this error. This would also explain the seemingly random nature of how many times I am seeing the error reported in my test. I will try out your _XCTIsTesting suggestion and see if that resolves it for me.

I'm still kind of a noob when it comes to iOS development, so even though I would love to split my code into separate targets, I think that's a bit over my head at the moment.

[mbrandonw]

Yep, you summarized that all correctly, and it's a very subtle problem that can be difficult to catch.

In my opinion it is a huge problem that the act of testing causes the simulator to fire up and start to execute your application's code. It is very surprising, and can create side effects that are hard to track down (such as files/databases/user defaults/etc... being clobbered).

[david-hosier]

Yes, totally agree. I am migrating my app to the ReducerProtocol, and I decided to make myself implement tests for the first time in an iOS app. I was very surprised to see the simulator starting up the first time I ran a test and had to research what was up with that. I kind of understand the rationale that I was able to find online, but it's still pretty concerning and makes running the tests that otherwise complete very quickly take an annoying amount of time to run.

Luckily my app starts/stops all the timers in a single place, so adding the _XCTIsTesting check was easy and fixed my issue. I appreciate your time and all the work you guys do on making awesome content for the community.