add ability to enter characteristics; Swift 6 and strict concurrency

[lukaskollmer]

add ability to enter characteristics; Swift 6

♻️ Current situation & Problem

HealthKit allows users to manually enter so-called characteristics into the Health app (eg: date of birth, wheelchair use, blood type, etc), which can then be read by apps.
This PR adds a function which allows automated entry of these characteristics as part of a UI test.
Furthermore, this PR also updates both the XCTHealthKit package itself, as well as the associated UITests app to Swift 6

This PR also makes the onboarding handling a public function, so that test cases can make use of this part of the package, without having to also enter e.g. a sample.

⚙️ Release Notes

• Added XCTestCase.launchHealthAppAndEnterCharacteristics(_:), to enter characteristics values into the health app
• Made XCTestCase.handleHealthAppOnboardingIfNecessary(_:) public

📚 Documentation

The new code is documented.

✅ Testing

There is a test that enters values for all supported characteristics.

Code of Conduct & Contributing Guidelines

By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

• I agree to follow the Code of Conduct and Contributing Guidelines.

[codecov]

Codecov Report

Attention: Patch coverage is 75.54585% with 56 lines in your changes missing coverage. Please review.

Project coverage is 78.43%. Comparing base (e3e319e) to head (d1089fb).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...rces/XCTHealthKit/XCTest+CharacteristicEntry.swift	81.21%	28 Missing ⚠️
Sources/XCTHealthKit/XCTest+HealthApp.swift	62.17%	28 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #17      +/-   ##
==========================================
+ Coverage   75.98%   78.43%   +2.45%     
==========================================
  Files           5        7       +2     
  Lines         383      547     +164     
==========================================
+ Hits          291      429     +138     
- Misses         92      118      +26     

Files with missing lines	Coverage Δ
Sources/XCTHealthKit/HealthAppCategory.swift	70.22% <ø> (ø)
Sources/XCTHealthKit/HealthAppSampleType.swift	87.50% <ø> (ø)
...rces/XCTHealthKit/XCTHealthKitAddSampleInput.swift	80.12% <100.00%> (+0.12%)	⬆️
Sources/XCTHealthKit/XCTest+AddSamples.swift	97.23% <100.00%> (+29.52%)	⬆️
Sources/XCTHealthKit/XCTest+HealthKit.swift	75.76% <100.00%> (ø)
...rces/XCTHealthKit/XCTest+CharacteristicEntry.swift	81.21% <81.21%> (ø)
Sources/XCTHealthKit/XCTest+HealthApp.swift	62.17% <62.17%> (ø)

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e3e319e...d1089fb. Read the comment docs.

[PSchmiedmayer]

Thank you for the updates; looks great!

I am wondering if we should (not here but at some point) add a prebuilt Button in a separate target here that writes a set of values in HealthKit from within the SUT (asks for write permissions and just reuses the structures we already have in this target to we share the same configuration as if we would enter them in the user interface) as well as a nice function into the XCTHealthKit target that the presses this button and handles the authentication flow. Might be worth it for some apps that don't want to follow the UI testing route as we also use that in SpeziHealthKit?

[lukaskollmer]

@PSchmiedmayer

Thank you for the updates; looks great!

I am wondering if we should (not here but at some point) add a prebuilt Button in a separate target here that writes a set of values in HealthKit from within the SUT (asks for write permissions and just reuses the structures we already have in this target to we share the same configuration as if we would enter them in the user interface) as well as a nice function into the XCTHealthKit target that the presses this button and handles the authentication flow. Might be worth it for some apps that don't want to follow the UI testing route as we also use that in SpeziHealthKit?

I thought about this as well, but my take (and the reason why i haven't done it so far) would be that the step of programmatically adding Health samples is actually super simple, and can trivially be done directly in the SUT, which would also allow the SUT much more control over the actual samples being created. (Unless our button would allow callers to specify this (eg: have a SampleDefinition type for specifying sample types, values, units, dates, etc), in which case we'd kinda end up unnecessarily recreating part of HealthKit via this mechanism.)
In many cases you probably also can't / don't want to add extra elements to your apps UI (think eg UI-testing a "real" app instead of our dedicated UITest apps), so in that case you'd probably still need the ability to enter samples directly via the Health App, unless you're fine with your app's UI when being UI-tested actually being slightly different from what real-world users would interact with.

I'm also not yet 100% sure what, if any, the differences between manually-entered Health data and programatically-entered data are (or for example whether there's a difference between data programmatically added in the current app vs programatically entered by some other app which happens to be in the background)