Context
Building reliable software involves writing unit tests ensuring that code works and continues to work as expected. With comScore SDK this process is made difficult since not only the software can change, but also the operating system it relies on, as well as the SDK itself.
Moreover comScore specifications we have to implement require us to validate our implementation when significant changes are made to our codebase, but also when the comScore SDK is updated. The validation process, involving manual checks with a proxy tool, is usually error-prone and might fail to detect regressions.
Currently the comScore SDK does not provide any official way to inspect what is actually sent to comScore servers. One approach could be to mock the comScore SDK in unit tests but since its internal state machine is quite complex we cannot be sure that what we currently mock matches how the SDK actually behaves. Tests relying on mocks might therefore not accurately reflect expectations.
In the past we have circumvented this issue by implementing a thin layer which is able to intercept comScore requests in unit tests (actually integration tests) so that we are able to inspect what is actually sent. This mechanism, based on notifications, would probably be beneficial to all teams implementing the comScore SDK.
Current workaround
Since quite some time we swizzle URLSession.dataTask(with:completionHandler:) in our unit tests to catch requests to scorecardresearch.com. The swizzled method unrolls the query parameter list, turns it into a dictionary and sends it in a notification which unit tests can listen to. This way we can write test expectations on what comScore actually sends so that we can ensure our integration is actually correct. We can for example check fields managed by the SDK like mp_v, ns_st_ldo or c2, but also streaming events and playhead positions.
This strategy make it possible for us to release updates with confidence, as we can automatically verify that various scenarios work as intended, most notably with streaming analytics.
We are in the process of rewriting our implementation in Swift and, though we already implemented the same trick, the situation is kind of fragile since comScore might rewrite its networking layer at any time. Thus this feature request.
Proposals
Here are a few proposals you might consider to offer such a mechanism:
- Send a notification through the default notification center when the comScore SDK performs a request.
- Provide request parameters in the notification user info dictionary, e.g. as a
[String: String] map.
- Provide this mechanism as an opt-in so that it can be only enabled in relevant targets (e.g. unit tests) and not in production builds.
- Make it possible to have events sent immediately so that tests can run in a short amount of time (not sure whether
SCORAnalytics.flushOfflineCache() can serve this purpose).
Android
The Android SDK is limited in the same way but since there is no swizzling on Android the situation is even more critical. If this makes sense I can open a similar feature request on the Android SDK repository.
Context
Building reliable software involves writing unit tests ensuring that code works and continues to work as expected. With comScore SDK this process is made difficult since not only the software can change, but also the operating system it relies on, as well as the SDK itself.
Moreover comScore specifications we have to implement require us to validate our implementation when significant changes are made to our codebase, but also when the comScore SDK is updated. The validation process, involving manual checks with a proxy tool, is usually error-prone and might fail to detect regressions.
Currently the comScore SDK does not provide any official way to inspect what is actually sent to comScore servers. One approach could be to mock the comScore SDK in unit tests but since its internal state machine is quite complex we cannot be sure that what we currently mock matches how the SDK actually behaves. Tests relying on mocks might therefore not accurately reflect expectations.
In the past we have circumvented this issue by implementing a thin layer which is able to intercept comScore requests in unit tests (actually integration tests) so that we are able to inspect what is actually sent. This mechanism, based on notifications, would probably be beneficial to all teams implementing the comScore SDK.
Current workaround
Since quite some time we swizzle
URLSession.dataTask(with:completionHandler:)in our unit tests to catch requests to scorecardresearch.com. The swizzled method unrolls the query parameter list, turns it into a dictionary and sends it in a notification which unit tests can listen to. This way we can write test expectations on what comScore actually sends so that we can ensure our integration is actually correct. We can for example check fields managed by the SDK likemp_v,ns_st_ldoorc2, but also streaming events and playhead positions.This strategy make it possible for us to release updates with confidence, as we can automatically verify that various scenarios work as intended, most notably with streaming analytics.
We are in the process of rewriting our implementation in Swift and, though we already implemented the same trick, the situation is kind of fragile since comScore might rewrite its networking layer at any time. Thus this feature request.
Proposals
Here are a few proposals you might consider to offer such a mechanism:
[String: String]map.SCORAnalytics.flushOfflineCache()can serve this purpose).Android
The Android SDK is limited in the same way but since there is no swizzling on Android the situation is even more critical. If this makes sense I can open a similar feature request on the Android SDK repository.