TCA & SwiftData: Testing?

[ghost]

Hello everyone,

I'm currently struggling with testing of a SwiftData-based TCA app.

The general problem I encountered is the fact, that although using @Dependency(\.uuid) for the custom properties of the entities that are defined, those entities (being @Models) have a Swift-Data-owned ObjectIdentifier.

When testing the addition of an entity, tests fail because that ObjectIdentifier always diverges from anything that you may compare with.

Are there any ideas how to cope with that problem?

• Hardy

[kamcma]

Hi @innoreq,

The maintainers have said that, in the future, there may be a more official story on TCA-SwiftData interop. But that does not exist yet.

With TCA today, it is not appropriate to have reference types (so: classes, as all SwiftData models are) in TCA state. You should wrap all your SwiftData interactions in a dependency, and that dependency should map all SwiftData models into value types (structs/enums) before returning them from the dependency into TCA state. This is how TCA has always worked with any dependencies vending reference types, including Core Data before SwiftData.

Basically: you should make some sort of persistence client as a dependency, and the interface of that dependency should deal entirely in value types, and the use of SwiftData should be purely an implementation detail of the live instance of the dependency client.

Therefore, any tests you write of TCA features using the TCA testing tools (eg TestStore) do not hit your live dependencies and never exercise SwiftData code. If you want to test your live persistence client, that's fine, but it exists entirely outside of TCA and TCA testing tools.

[mbrandonw]

Hi @innoreq, I'm having a hard time understanding the exact issue you are running into. Can you cook up a very minimal project that demonstrates the problem?

[Narsail]

@mbrandonw I assume it is a similar scenario that I encountered today. I plan on migrating my App to TCA and started with one of my Tabs which is rather simple: A List of Exercise, a drill down detail view and a view to create an exercise. I played around with the non-exhaustive test flows today and hit the issue that relationships are set differently in the modelContext than in a fresh initialised model.

So the following code:

func testAddNewExercise() async {
        let store = TestStore(initialState: ExerciseList.State()) {
            ExerciseList()
        } withDependencies: {
            $0.uuid = .incrementing
        }
        store.exhaustivity = .off
        
        await store.send(.viewAppeared)
        
        store.assert {
            $0.destination = nil
            $0.sortedAndFilteredExercises = []
        }
        
        await store.send(.createExerciseButtonTapped)
        await store.send(.destination(.presented(.createExercise(.setName("New Exercise")))))
        await store.send(.destination(.presented(.createExercise(.tappedEquipmentCell(.Barbell)))))
        await store.send(.destination(.presented(.createExercise(.saveButtonTapped))))
        await store.skipReceivedActions()
        
        let exercise = ExerciseSwiftData(
            id: UUID(0),
            name: "New Exercise",
            custom: true,
            softDeleted: false,
            category: .WholeBody,
            equipment: [.Barbell]
        )
        
        store.assert {
            $0.destination = nil
            $0.sortedAndFilteredExercises = [
                ExerciseSwiftData(
                    id: UUID(0),
                    name: "New Exercise",
                    custom: true,
                    softDeleted: false,
                    category: .WholeBody,
                    equipment: [.Barbell]
                )
            ]
        }
    }

fails with

ExerciseList.State(
        allSearchTokens: […],
        _exercises: […],
        _sortedAndFilteredExercises: [
          [0]: ExerciseModelV2(
            _id: ExerciseModelV2._SwiftDataNoType(),
            _createdAt: ExerciseModelV2._SwiftDataNoType(),
            _name: ExerciseModelV2._SwiftDataNoType(),
            _custom: ExerciseModelV2._SwiftDataNoType(),
            _softDeleted: ExerciseModelV2._SwiftDataNoType(),
            _categoryString: ExerciseModelV2._SwiftDataNoType(),
            _equipmentStrings: ExerciseModelV2._SwiftDataNoType(),
    −       _instructionReferences: nil,
    +       _instructionReferences: ExerciseModelV2._SwiftDataNoType(),
    −       _activityReferences: nil,
    +       _activityReferences: ExerciseModelV2._SwiftDataNoType(),
    −       _progressItemsReferences: nil
    +       _progressItemsReferences: ExerciseModelV2._SwiftDataNoType()
          )
        ],
        _searchText: "",
        _selectedTokens: [],
        _destination: nil
      )

Is there a way of configuring which values will be compared? I.e. to exclude _instructionReferences in the comparison?

FYI - after reading @kamcma comments I will consider banishing SwiftData models from the TCA logic completely, still, I'm interested in how I could configure test asserts as I didn't find anything about it in the docs.

[Narsail]

@mbrandonw I found a statement from you about assertions here: #2179 (reply in thread)

Maybe that is all what I need. Can you point me to some documentation or an example of how I can test individual fields? Alternatively it would be already enough to test the count of the array I'm comparing with. But I have no clue how to do that.

[kamcma]

@Narsail, there are TCA tools coming that may bear on TCA-SwiftData interop. Please watch these repo discussions for an announcement re: "shared state".

[Narsail]

I will keep an eye on it!

Btw NVM around the way to assert my test outputs. I could just do an XCAssert of the store state 🤦‍♂️