Building tests as a dynamic library rather than an executable

Development Swift Testing
,
1

I'm trying to scope out how hard it would be to have an option to build the test runner as a shared object file rather than an executable. E.g., instead of:

$ ~/Library/Developer/Toolchains/swift-6.2-DEVELOPMENT-SNAPSHOT-2025-05-15-a.xctoolchain/usr/bin/swift build --swift-sdk aarch64-unknown-linux-android28 --build-tests

[134/134] Linking swift-android-nativePackageTests.xctest
Build complete! (10.87s)

$ file .build/aarch64-unknown-linux-android28/debug/swift-android-nativePackageTests.xctest
.build/aarch64-unknown-linux-android28/debug/swift-android-nativePackageTests.xctest: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, BuildID[sha1]=247b4af289578f215fd136d07815ef2eb3a874db, with debug_info, not stripped

…I would rather have a swift-android-nativePackageTests.so with a testingMain() function that I can invoke within the context of an Android app.

The reason I need this is that while the test executable runs fine from an Android adb shell (modulo some quirks), to have access to the full Android Java SDK, it needs to be run in the context of a proper .apk app rather than a command-line tool.

And guidance or suggestions for where I might start my investigation would be appreciated.

2

Simply changing the build product to a dynamic library is pretty straightforward in the SwiftPM repo, and it's not dissimilar to what we do on Darwin to build a .xctest bundle (which is just a dynamic library in a fancy hat.) When a test target is run on iOS (using Xcode), it is hosted in your app, so something similar on Android makes sense to me.

I don't think we'd want to change the target type for Linux, but for cross-compilation to Android, I can appreciate why it would be useful. I think @dschaefer2 and his colleagues might have more ideas here. (Note: if you do pursue a change, please run it past the TWG first so there aren't any surprises. :smiley:)

1 Like
3

I actually wonder if moving towards test bundles being shared libraries on all platforms[1] might be useful and help simplify some things in SwiftPM. Currently, it has diverging logic for different platforms and environments in how it builds and launches test bundles.

  1. At least, on platforms where they're supported. ↩︎

2 Likes