Fixed issue with early test observer registration preventing console output #271
Conversation
|
Agreed I've run this locally and verified it works – thanks @paweldudek for such a quick turnaround on this 🙇 I'm going to defer to @jeffh on merging. |
| @@ -12,7 +12,14 @@ @implementation CurrentTestCaseTracker (Register) | |||
|
|
|||
| + (void)load { | |||
| CurrentTestCaseTracker *tracker = [CurrentTestCaseTracker sharedInstance]; | |||
| [[XCTestObservationCenter sharedTestObservationCenter] addTestObserver:tracker]; | |||
| // XCode 7.3 introduced a bug where early registration of a test observer prevented | |||
| // default XCTest test observer from being registered. That caused no longs being printed | |||
There was a problem hiding this comment.
typo longs -> logs; XCode -> Xcode
thanks for the quick PR!
There was a problem hiding this comment.
Nice catch! Let's fix this in another PR/commit.
There was a problem hiding this comment.
created #272 to address this 👍
|
LGTM, thanks for the quick response! Normally I'd defer to @jeffh, but in the interest of unbreaking people's workflow I'll merge this now. If we ever think of a more elegant approach we can fix forward. |
|
@paweldudek mind sending a PR to bump the Nimble submodule in Quick? |
|
@modocache looks like @ashfurrow was faster than me 😉 |
Fixed issue with early test observer registration preventing console output
A small typo in documentation
This PR is an attempt to fix #270.
It looks like that early test observer registration (aka as early as you can - in
+load) prevents default XCTest observer from registering in latest XCTest that shipped with Xcode 7.That default observer is responsible for printing output to Xcode console (or Terminal when running
xcodebuildfrom command line). There are several tools that rely on this output, for instancexcpretty.This simple PR adds logic that defers the moment where
CurrentTestCaseTrackerand thus allows default XCTest observer to register.Potential issues: There should not be any issues with
CurrentTestCaseTrackerbeing registered too late as we're moving the registration to next run loop cycle (which is the moment after all classes and categories get their+loadmessage). However I'm entirely certain about and any input on whether this is a viable solution is welcomed.Or perhaps better alternatives, as I'm not a huge fan of using
dispatch_asyncthis way 😉I've tested this against my test suite and it works just fine.