Ancestors

Written by Rob Napier on 2025-01-30 at 23:18

I'm a bit confused why some most frameworks in SPM build as X.framework, but a few build as X__PackageProduct.framework.

I have one of those, and it seems to be linking twice in my unit tests, leading to two copies of a static variable.

I'm certain I have two copies of a static variable, but I'm not yet certain it's related to the "PackageProduct."

=> More informations about this toot | More toots from cocoaphony@mastodon.social

Written by Rob Napier on 2025-01-31 at 02:56

My current suspicion is it’s related to how I’m importing things. A imports B. The app imports both A and B. The tests import A.

The B the app sees is different than the B the tests see.

I might be able to figure out the right Package config, but just moving B into A also seems to fix it, and that’s not bad in this case.

I’m not sure how much it would take to make an example project. The fact that there are two repositories might matter. I’ll see.

But I wish I knew what PackageProduct meant.

=> More informations about this toot | More toots from cocoaphony@mastodon.social

Written by Rob Napier on 2025-01-31 at 22:27

I am pretty sure I’ve figured it out. The test target for hosted Xcode tests is a plugin. If you have a test target that depends on things that your app also depends on, the test target will get its own copy of the frameworks. That will lead to collisions that will mostly work, but can lead to duplicate statics for example.

Currently I’m exploring how to remove that dependency. It breaks the test’s build of course. I’m exploring wrapping the shared code in a “if canImport” which might work.

=> More informations about this toot | More toots from cocoaphony@mastodon.social

Toot

Written by Olivier Halligon on 2025-02-01 at 01:12

@cocoaphony idk if this is possible in a SPM-only setup, but in an xcodeproj this kind of situation can be avoided for unit tests by removing the app as being the TEST_HOST builds setting for the test app. [1/3]

=> More informations about this toot | More toots from aligatr@ohai.social

Descendants

Written by Olivier Halligon on 2025-02-01 at 01:13

@cocoaphony If you do that you'll have to add all the source files of the app target that your unit test requires (models, SUTs…) to the test target too of course (or move those common files to a shared framework linked by each), but at least your test target won't be loaded as a plugin to your app target by the test harness anymore, removing the double-loading of symbols. [2/3]

=> More informations about this toot | More toots from aligatr@ohai.social

Written by Olivier Halligon on 2025-02-01 at 01:20

@cocoaphony Of course this is not applicable to UI Tests, which do need to be loaded as plugins into the app binary for them to be able to control the app's UI from within, so it's not always that simple.

Also, I am not sure why Apple makes the app target be the TEST_HOST of newly-created test targets by default (I think), as to me it'd be better conceptually to make Unit Tests targets independent of app's UI code and only link to models under test… 🤷 [3/3]

=> More informations about this toot | More toots from aligatr@ohai.social

Written by orj on 2025-02-01 at 03:12

@aligatr @cocoaphony I’m a big advocate for not using hosted tests and for the app target being almost as lean as a single main.swift (when possible).

=> More informations about this toot | More toots from orj@mastodon.social

Written by Michael McGuire on 2025-02-01 at 05:48

@aligatr @cocoaphony for the record: UITests are not loaded as a plugin into the app binary to control the app’s UI. They run as a completely separate process and interact through Accessability API’s. They are fully out of process.

=> More informations about this toot | More toots from monocularvision@mastodon.social

Written by Olivier Halligon on 2025-02-01 at 09:02

@monocularvision @cocoaphony Ah, indeed, thanks for the correction 👍

=> More informations about this toot | More toots from aligatr@ohai.social