My solution uses a combination of macOS accessibility APIs and CGEvents directly (not keyDown), the former of which understands the whereabouts of the simulator, the latter for how to find the center of the viewport, set up a two-finger gesture by spawning at the center, option-dragging to a specified input distance, option-shift-dragging to a specified coordinate, then performing one or more gestures therein.

There has to be a better way!?

#RandomForms #swiftui #SwiftTesting #macos

#iosdev #buildInPublic #coredata #swiftTesting

Random thoughts for future development:
Object identity is not straightforward.

If I change a collection name on device A, the change should propagate to device B.
Should two collections with the same name on different devices but with different members be merged? I think the principle of least surprise would argue that they should.

OTOH, two tunes with the same name but different melodies should be distinct (common in #irishmusic)

29/n

#iosdev #buildInPublic #coredata #swiftTesting

Not much time to do stuff over the last little while - refactored the unit tests to parameterize them and added some helper functions, added a runtime flag to choose a real file for the SQLite backing store vs. /dev/null
Changes are in GitHub if anybody is interested https://github.com/Wil-Macaulay/attributedRelationships

28/n

#iosdev #buildInPublic #coredata #swiftTesting

Will be exploring Apple’s cktool for #cloudkit setup, which hopefully will let me populate data that will let me test sync

https://developer.apple.com/icloud/ck-tool/

27/n

#iosdev #buildInPublic #coredata #uikit #swiftTesting

This is going to be super important when I change the underlying data model. Maybe I should add a little facade over the CoreData so I can preserve the API and leave the unit tests unchanged? That’s the ideal when refactoring, run the exact same suite of tests and have them succeed.

Still not sure on my approach for testing when synchronization across multiple devices…

26/n

#iosdev #buildInPublic #coredata #uikit #swiftTesting

Added my first set of unit tests - just creating a single instance of each of my core entities - pushed to GitHub for those that care! Next step is to add tests for the relationships: for example, adding a Tune to a TuneSet and then reordering them.
Found a neat trick on testing Core Data without leaving droppings - use /dev/null as the store. See
https://medium.com/tiendeo-tech/ios-how-to-unit-test-core-data-eb4a754f2603

25/n