testGeoJSON() fails intermittently (probably slow decoding)

[1ec5]

V5Tests.testGeoJSON() has been failing occasionally for months, but ever since #382 landed, it has been failing much more frequently:

Test Case '-[MapboxDirectionsTests.V5Tests testGeoJSON]' started.
/Users/distiller/project/Tests/MapboxDirectionsTests/V5Tests.swift:64: error: -[MapboxDirectionsTests.V5Tests testGeoJSON] : Asynchronous wait failed: Exceeded timeout of 5 seconds, with unfulfilled expectations: "calculating directions should return results".
/Users/distiller/project/Tests/MapboxDirectionsTests/V5Tests.swift:65: error: -[MapboxDirectionsTests.V5Tests testGeoJSON] : XCTAssertNil failed: "Error Domain=com.apple.XCTestErrorDomain Code=0 "(null)"" - Error: Error Domain=com.apple.XCTestErrorDomain Code=0 "(null)"
/Users/distiller/project/Tests/MapboxDirectionsTests/V5Tests.swift:73: error: -[MapboxDirectionsTests.V5Tests testGeoJSON] : XCTAssertNotNil failed
Test Case '-[MapboxDirectionsTests.V5Tests testGeoJSON]' failed (5.306 seconds).

This is most likely a symptom of the Codable performance issue raised in #221 (comment). The issue lies upstream in Turf, which this library relies on to decode LineStrings, and technically further upstream in the Swift standard library.

This isn’t necessarily a showstopper, since the navigation SDK uses Polyline encoding by default instead of GeoJSON. However, we should find a way to get performance back to within the same ballpark as it was before adopting Codable. If it’s already in the same ballpark, then we should increase the timeout and also add a performance unit test to make any runtime changes more apparent.

/cc @mapbox/navigation-ios @frederoni

[1ec5]

I’m not sure if equality comparisons are contributing to the test’s flakiness, but we could improve equality performance by storing Polyline-encoded representations of Route.shape and RouteStep.shape and comparing those strings instead of the full LineString structs.

Locally, testGeoJSON() takes a little over a second with a 10% standard deviation, much less than the 5-second timeout. I’m getting suspicious that this is something other than a performance issue.

[1ec5]

Per #354 #353 (comment), the failures may be due to a race condition or other nondeterminism rather than poor performance.

[1ec5]

Fixed for now in #404. If it is a race condition, we can revisit it when it comes up in some other form, but this end-to-end test isn’t a good vehicle for understanding any concurrency issue.