Figured out how to run tests for iOS: ``` xcrun simctl spawn '<sim name like iPad Air 2>' <...

# multiplatform

[basher]

Figured out how to run tests for iOS:

xcrun simctl spawn '<sim name like iPad Air 2>' <path to test.kexe>

[basher]

Filed an issue here: https://github.com/JetBrains/kotlin-native/issues/2578

[alec]

https://github.com/JetBrains/kotlin-mpp-example/blob/master/greeting/build.gradle#L80

[alec]

agree this should just be handled automatically

[alec]

i imagine they havent because part of that task references a target you define

[icarumbas]

Isn’t it already exists? https://github.com/JetBrains/kotlin-mpp-example/blob/master/greeting/build.gradle

[russhwolf]

Examples exist but it isn't provided by default (either in the plugin or in the new project templates)

[basher]

@maxim that build.gradle shows them creating a custom task to do it

[basher]

IMO, it should be built into the plugin

[icarumbas]

@basher got it now. Thanks

[basher]

Np!

[basher]

i imagine they havent because part of that task references a target you define

@alec i'm referencing a task generated from the kotlin-multiplatform plugin. Seems like fromPreset (or targetFromPreset in 1.3.20) could just generate this task too

[alec]

yup they could at the very least create a test task for each target iosDeviceTest

[alec]

i could add it to our cocoapods plugin 😉

[russhwolf]

But something still needs to tell it which simulator to use. Just having a target defined doesn't specify that

[alec]

i still need to figure out the best way how to get these tests to run as part of a CI build w/ cocoapods

[basher]

Heh yeah 🙂

[alec]

yea the task in their example defaults to an iPhone 8 simulator

[basher]

@russhwolf agree, but it could specify a default and then allow it to be altered as a variable in the fromPreset block

[basher]

If it wanted to be extra fancy (and verbose), it could run xcrun simctl list and output one task per sim. It'll generate a lot of tasks, but the could be configurable as well?

[russhwolf]

yeah I agree. I just mention it to highlight that there are some API decisions to make before integrating it into the plugin, which maybe is why they haven't yet

[basher]

Good point!

[basher]

@alec the more I think about it, it prob makes sense to have a generic iOS plugin

[basher]

The maintenance burden of this feels beyond the scope of K/N