Harmonize fixture logging #1601
Conversation
|
Generated by 🚫 Danger |
| @@ -1,4 +1,5 @@ | |||
| #import "Scenario.h" | |||
| #import "Logging.h" | |||
There was a problem hiding this comment.
Do we really need to include the header in all the scenario files, when there are no other changes?
There was a problem hiding this comment.
Scenario.h is currently the bridging header, so anything it sees, Swift sees, which causes problems with the naming clash. We could try hoisting the things Swift needs out into another header file, but I ran out of time. I can look again later.
| @@ -66,11 +67,11 @@ - (void)run { | |||
| - (void)consumeAllMemory { | |||
| struct utsname system = {0}; | |||
| uname(&system); | |||
| NSLog(@"*** Device = %s", system.machine); | |||
| logInfo(@"*** Device = %s", system.machine); | |||
There was a problem hiding this comment.
From my perspective, logs like these are too low-level to have the same prefix. What I'd really like to do is come to a device log and be able to quickly get a medium-level context of what's going on with the e2e tests. So (for me) these things are all really valid:
- Launching the app
- Finding reading the fixture config file
- Polling for commands
- Starting scenarios
- etc
But things that are very scenario specific I would rather leave to normal logging, as not to dilute the power of being able to focus in on an area very quickly. Maybe we could have another standard prefix for the more detailed stuff?
There was a problem hiding this comment.
We could add a "debug" channel for stuff like this...
| @@ -218,28 +213,29 @@ + (void)clearPersistentData { | |||
| } | |||
|
|
|||
| + (void)executeMazeRunnerCommand:(void (^)(NSString *scenarioName, NSString *scenarioMode))preHandler { | |||
| NSLog(@"%s", __PRETTY_FUNCTION__); | |||
| logInfo(@"%s", __PRETTY_FUNCTION__); | |||
There was a problem hiding this comment.
Same for me here - worthy of logging, for sure, but breaks the level of abstraction that I had been aiming for.
Goal
This PR harmonizes all of the logging in the CI fixtures so that they all use the same function names (
logInfo,logWarn,logError) in Swift and Objective-C, and support optional varargs. These log functions all go to the same "channel" that prefixesbugsnagci <level>so that the fixture messages can easily be filtered by common tooling.