Posts

Post marked as solved
3 Replies
3.9k Views
I'm using Xcode 11.5.I'm using test plans.I have an app that uses several local Swift Packages.When I test the app, I'd like to run the tests for the packages.In the current scheme I've tried putting a checkmark for "SomePackageTests" under the Test column in the Build action.The test plan, "SomeTestPlan", seems to show up as its own target in the Build action. It has a disclosure icon to its left. When I expand, I see the test targets for the app and for all local packages. The expanded test targets don't have their own checkboxes. I've also tried putting a checkmark for "SomeTestPlan" itself under the Test column in the Build action.When I edit the test plan, I see the test targets for the app and for all local packages. I've tried enabling the package tests there too.The app tests (unit and UI) build and run successfully. For example, they show up in the test navigator. I can right-click on them, select "Run", and they build and run successfully.The package tests are also listed in the test navigator. They build successfully—I see a "Build Succeeded" message pop up—but they don't run successfully. The error looks like this: 2020-05-26 11:03:33.947959-0400 xctest[55965:34366669] Failed to create a bundle instance representing '/Users/someuser/Library/Developer/Xcode/DerivedData/SomeApp-eecekbbecwouyeagzirvwewncpem/Build/Products/Alpha-Debug-iphonesimulator/SomePackageTests.xctest'. Check that the bundle exists on disk. Program ended with exit code: 1(Note that "Alpha-Debug" is the name of both a build configuration and a test plan. I assume the above is a reference to the test plan, but I could be wrong.)I *think* the problem is that Xcode is looking in the wrong place—but only for the package tests, not the app tests.It's correct that there's no directory at that location. There is, however, a directory by that name in this location: /Users/someuser/Library/Developer/Xcode/DerivedData/SomeApp-eecekbbecwouyeagzirvwewncpem/Build/Products/Variant-UBSan/Alpha-Debug-iphonesimulator/SomePackageTests.xctest/Here's the key difference.The first path has ".../Products/Alpha-Debug...".The second path has ".../Products/Variant-UBSan/Alpha-Debug..."."UBSan" is the name of my default (and one-and-only) test configuration in the test plan.So: it seems like building builds to a test configuration dir, but running looks in a non-test configuration dir. At least for packages.Is this an Xcode bug, or did I misunderstand something?Again, the goal is to run all of my package tests when I test my app.PS I *think* this was working before I switched to test plans, but I'm not absolutely certain.
Posted
by mul.
Last updated
.
Post not yet marked as solved
3 Replies
1.9k Views
WWDC 2019 Session 230 (Making Apps with Core Data) introduced a new Core Data feature, derived attributes. In a demo of the feature a postCount attribute was added to an entity, with the derived expression of "posts.@count". As far as I can tell the demo only worked because the context was "fresh". If you make any changes to a context, derived expressions yield stale results, even after the context is saved. Only a call to context.refreshAllObjects() (or context.reset()) refreshes them. To state that a bit differently, using the demo's example: tag.posts.count yields a correct value after context.save(), but tag.postCount does not. Until, that is, you call context.refreshAllObjects(). Or context.reset().I filed a bug, together with a sample app.
Posted
by mul.
Last updated
.
Post not yet marked as solved
5 Replies
2.4k Views
Core Data with CloudKit doesn't seem to document how changes get merged. (I filed a bug, but maybe we can collectively scratch out some details here?)As far as I can tell, Core Data with CloudKit uses a "last writer wins" approach at the attribute level, and a "last writer wins + merge" approach at the relationship level.Here's an experiment:1. Create a Core Data with CloudKit app2. Create an entity with two text attributes: text1, text23. Create an instance of that entity, set some values in text1 and text2, and sync it across two devices4. Disconnect the two devices from the network5. On device 1, set text1 to "aaa" and leave text2 as is. Save the changes.6. On device 2, set text2 to "bbb" and leave text1 as is. Save the changes.7. Reconnect both devices to the network and allow them to sync.8. I believe the final result will be that the entity has "bbb" in text2 and the original value in text1, because device 2 saved its changes after device 1.The thing to note is that the two changes weren't merged even though they changed different attributes. (As far as I can tell the Core Data merge policy is irrelevant when it comes to CloudKit merges.)I'm not making any comment on whether this behaviour is good or bad, right or wrong; I'm just saying that it should be documented.(I think the picture for relationships is a little more complex. I think to-one relationships are "last writer wins" while to-many relationships are "merge"—but there are some important experiments I haven't conducted yet.)
Posted
by mul.
Last updated
.