In the upcoming NetworkConnectivityTests we’ll definitely want to be able to see the log output from the Asset Tracking SDKs. So, here I’ve added some ready-made log handlers that can be used by all of the tests, and added logging to the existing system tests (where, again, I think it’s useful to be able to see the SDKs’ logs sometimes).
The logging implementation uses NSLog. I wanted to use swift-log, like in the example apps, to give us the option of using our LogParser library to parse the logs. But adding swift-log as a dependency – even if one whose products are only used by the tests – affects the dependency graph of the entire package. Specifically, it could cause a version requirements clash for other packages that use the AAT SDKs and also have their own dependency on swift-log. See this Swift Forums post:
The only part of the picture that isn’t finished yet is that unused dependencies still affect the version compatibilities of your dependency graph.
In the upcoming
NetworkConnectivityTestswe’ll definitely want to be able to see the log output from the Asset Tracking SDKs. So, here I’ve added some ready-made log handlers that can be used by all of the tests, and added logging to the existing system tests (where, again, I think it’s useful to be able to see the SDKs’ logs sometimes).The logging implementation uses
NSLog. I wanted to useswift-log, like in the example apps, to give us the option of using ourLogParserlibrary to parse the logs. But addingswift-logas a dependency – even if one whose products are only used by the tests – affects the dependency graph of the entire package. Specifically, it could cause a version requirements clash for other packages that use the AAT SDKs and also have their own dependency onswift-log. See this Swift Forums post: