# The testee of xctest\_add\_bundle
**URL:** https://discourse.cmake.org/t/the-testee-of-xctest-add-bundle/10120
**Category:** Development
**Created:** [February 17, 2024, 5:39am UTC](https://discourse.cmake.org/t/the-testee-of-xctest-add-bundle/10120 "2024-02-17T05:39:12Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@dabrahams](https://discourse.cmake.org/u/dabrahams)
#### Post date: [February 17, 2024, 5:39am UTC](https://discourse.cmake.org/t/the-testee-of-xctest-add-bundle/10120/1 "2024-02-17T05:39:12Z")
I’ve been working on a [little package](https://github.com/hylo-lang/SwiftCMakeXCTesting) that could be thought of as a modernization of `FindXCTest`, which is a bit dated at this point. `FindXCTest` only supports Apple platforms, but XCTest is now available on Windows and Linux as part of Swift distributions. And the support for Apple platforms is outdated or incomplete, as [these workarounds](https://github.com/hylo-lang/SwiftCMakeXCTesting/blob/12e64e0d1c7a422f01e4601eadefa743811e45f5/cmake/modules/SwiftCMakeXCTesting.cmake#L4C1-L22C1) are needed to make it work with Swift.
My package uses FindXCTest on Apple platforms, and from it, inherits a “testee” parameter requirement… but this requirement seems a bit suspect. Swift Package Manager (for example) lets me declare and run XCTest targets with no testee, so it seems like a testee must not be inherently needed. In fact, the testee plays no special role as far as I can tell: `SwiftCMakeXCTesting` itself creates an empty dummy testee just to satisfy this requirement. Looking at [the source code](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/FindXCTest.cmake) of `FindXCTest` is even more revealing:
- The code supports the use of a static library as the testee, and my tests indicate that passing a static library target does in fact work , even though the documentation clearly forbids it.
- The only interesting thing that happens with library testees—once their (seemingly needless) framework requirement is validated, if the library is shared—is that they are linked into the test target being declared with `target_link_libraries`. But that’s the sort of thing you would have to do with any other library dependency of the test, and it’s very common for my tests to depend on more than one library, so I’ll be making other calls to `target_link_libraries`. It seems weird to give this one library dependency special status.
- That leaves application testees, for which there is [some special logic](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/FindXCTest.cmake#L151-173), which _looks_ like it’s what’s needed to treat an application bundle as a library. That seems like a generally-useful (but platform-specific) bit of functionality that ought to be vended as its own “thing,” independent of testing.
My inclination at this point is to stop relying on `xctest_add_bundle` and replicate the key parts of its functionality in my own package, freeing my APIs from the idea of a “testee,” but a) that seems like a shame, and b) I’m concerned I might be overlooking something. So
- Can anyone shed light on the rationale for the current design?
- Does my proposed approach make sense, or is there a better way?
Thanks!
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [February 17, 2024, 6:43am UTC](https://discourse.cmake.org/t/the-testee-of-xctest-add-bundle/10120/2 "2024-02-17T06:43:32Z")
Cc: @gjasny
> [@dabrahams](#):
>
> The code supports the use of a static library as the testee, and my tests indicate that passing a static library target does in fact work , even though the documentation clearly forbids it.
See [https://gitlab.kitware.com/cmake/cmake/-/issues/16636](https://gitlab.kitware.com/cmake/cmake/-/issues/16636)
---
### Author:  [@dabrahams](https://discourse.cmake.org/u/dabrahams)
#### Post date: [February 17, 2024, 6:52pm UTC](https://discourse.cmake.org/t/the-testee-of-xctest-add-bundle/10120/3 "2024-02-17T18:52:35Z")
> [@ben.boeckel](#):
>
> See [https://gitlab.kitware.com/cmake/cmake/-/issues/16636](https://gitlab.kitware.com/cmake/cmake/-/issues/16636)
Thanks @ben.boeckel; I followed the link. It shows the commit that added the cmake code I was referring to that supports static libraries (without fixing the documentation to allow their use). I feel like you were maybe trying to say something more though. Was following the link supposed to reveal anything else of relevance?
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [February 17, 2024, 6:57pm UTC](https://discourse.cmake.org/t/the-testee-of-xctest-add-bundle/10120/4 "2024-02-17T18:57:14Z")
No, sorry. This is not my field; I Cc’d Gregor Jasny who started the module and then provided context on the static library bit. I’ve not enough background to understand what pros and cons might be around it (sorry, I should have been more explicit).
---
### Author:  [@dabrahams](https://discourse.cmake.org/u/dabrahams)
#### Post date: [February 22, 2024, 7:16pm UTC](https://discourse.cmake.org/t/the-testee-of-xctest-add-bundle/10120/5 "2024-02-22T19:16:04Z")
In that case, @gjasny your input here would be most welcome.