How to prevent app storage with defined store to leak among tests?

[jiledaa]

Hello, when define app storage like:

extension SharedReaderKey where Self == AppStorageKey<Bool>.Default {
    static var areDevicesEmpty: Self {
        return Self[.appStorage("myKey", store: UserDefaults(suiteName: "mySuite")), default: true]
    }
}

how to change suitename for tests to prevent failed - '@shared(.appStorage("areDevicesEmpty"))' was given a new store object for an existing suite name ("mySuite")? In your app storage example tests I found just one test on the bottom that did not answer this for me.

Regards, David.

[stephencelis]

@jiledaa It is not valid to construct a store with a suite name like this. If you expand the warning it tells you how to address the problem:

swift-sharing/Sources/Sharing/SharedKeys/AppStorageKey.swift

Lines 271 to 284 in c9fd8da

	'@Shared(\(self))' was given a new store object for an existing suite name \
	(\(suiteName.debugDescription)).
	Shared app storage for a given suite should all share the same store object to \
	ensure synchronization and observation. For example, define a store as a \
	'static let' and refer to this single instance when creating shared app storage:
	extension UserDefaults {
	nonisolated(unsafe) static let mySuite = UserDefaults(
	suiteName: \(suiteName.debugDescription)
	)!
	}
	@Shared(.appStorage(\(key.debugDescription), store: .mySuite) var myProperty

Let us know if you have any other questions!

[jiledaa]

Ah right, as I use one get instance, the tests stop leaking with this app storage shared. However, in tests I can see another weird behavior.
Having:

extension SharedReaderKey where Self == AppStorageKey<Bool>.Default {
    static var areDevicesEmpty: Self {
        Self[
            .appStorage(
                "MyKey",
                store: .sharedDefaults
            ),
            default: true
        ]
    }
}

public extension UserDefaults {
    nonisolated(unsafe) static let sharedDefaults: UserDefaults? = UserDefaults(
        suiteName: CoreConstants.FileStorageIdentifier.appGroupID
    )
}

and:

@Reducer
struct Reducer {
    @ObservableState
    struct State: Equatable {
        @Shared(.areDevicesEmpty) var areDevicesEmpty: Bool
    }

    enum Action {
        case aaa
        case bbb
    }

    var body: some ReducerOf<Self> {
        Reduce { state, action in
            switch action {
            case .aaa:
                return .send(.bbb)

            case .bbb:
                state.$areDevicesEmpty.withLock { $0 = true }
                return .none
            }
        }
    }
}

import Testing

@MainActor
struct TestReducer {
    @Test
    func test1() async {
        @Shared(.areDevicesEmpty) var areDevicesEmpty: Bool
        $areDevicesEmpty.withLock { $0 = false }
        let store = TestStore(initialState: Reducer.State(), reducer: Reducer.init)

        await store.send(.aaa)
        await store.receive(.bbb) { state in
            state.$areDevicesEmpty.withLock { $0 = true }
        }
    }
}

❌ for await store.send(.aaa) there is: Reducer.State(
− _areDevicesEmpty: #1 false
+ _areDevicesEmpty: #1 true
  )

@MainActor
struct TestReducer {
    @Test
    func test1() async {
        @Shared(.areDevicesEmpty) var areDevicesEmpty: Bool
        $areDevicesEmpty.withLock { $0 = false }
        let store = TestStore(initialState: Reducer.State(), reducer: Reducer.init)

        await store.send(.aaa) { state in
            state.$areDevicesEmpty.withLock { $0 = true }
        }
        await store.receive(.bbb)
    }
}

✅ this passes, but does make sense.

[stephencelis]

@jiledaa This is due to a gotcha we will document here: https://github.com/pointfreeco/swift-composable-architecture/blob/5b74abe329a04e4474b70712c95001a5916ff189/Sources/ComposableArchitecture/Documentation.docc/Articles/SharingState.md#tests

The test store currently eagerly processes all actions it receives against state, and shared properties are referential, which forces you to assert against them in the first action of a batch of actions processed at the same time.

We should be able to address this in a 2.0, but it would be a breaking change to fix in 1.x.

[jiledaa]

Ok, thanks for the answer.