Exercise public APIs in Swift integration tests

[1ec5]

Sometimes we make changes like #8541 that, per our versioning guidelines, don’t warrant a major version bump but may break backwards compatibility in Swift code due to the vagaries of Objective-C-to-Swift bridging. Avoiding these changes would be a major burden on development, but we should have a system for tracking them, to ensure that we communicate those changes in release notes.

Most of our unit tests are written in Objective-C, which is unable to catch changes to Swift bridging. We should supplement these unit tests with integration tests written in Swift that exercise the public APIs. At a minimum, they should call methods, implement delegate methods, etc., but they wouldn’t necessarily verify the results – that would remain the responsibility of the Objective-C++ unit tests, which have access to the underlying mbgl types.

/cc @mapbox/ios

[boundsj]

#8729 added integration tests for MGLMapViewDelegate. It also introduced a utility to help ensure test coverage. That utility and pattern introduced in #8729 can be used to help test our other protocols (i.e. MGLOfflineStorageDelegate, MGLOverlay, MGLCalloutViewDelegate)

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.

[friedbunny]

With recent Swift interface troubles around implementing optional location manager properties, this remains a valid issue.

/cc @riastrad @1ec5 @julianrex @frederoni

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.