Logging seems excessive

[rhgills]

Consider the output of a single test case, all of which is from the framework and none from the actual test.

Test Case '-[TyphoonXmlComponentFactoryTests test_returns_component_from_factory_component]' started.
2013-07-23 10:18:11.653 otest[38865:303] Resource: MiddleAgesAssembly.xml
2013-07-23 10:18:11.654 otest[38865:303] Registering: Knight with key: knight
2013-07-23 10:18:11.654 otest[38865:303] $$$$$$$$$$$$$$ Here's the injected property: <TyphoonPropertyInjectedAsCollection: self.  name=favoriteDamsels, _values=(
    "<TyphoonTypeConvertedCollectionValue: self.textValue=mary, self.requiredType=NSString>",
    "<TyphoonTypeConvertedCollectionValue: self.textValue=jane, self.requiredType=NSString>"
)>
2013-07-23 10:18:11.655 otest[38865:303] $$$$$$$$$$$$$$ Here's the injected property: <TyphoonPropertyInjectedAsCollection: self.name=friends,   _values=(
    "<TyphoonByReferenceCollectionValue: 0x108117870>",
    "<TyphoonByReferenceCollectionValue: 0x108102430>"
)>
2013-07-23 10:18:11.655 otest[38865:303] Registering: Knight with key: knightWithCollections
2013-07-23 10:18:11.655 otest[38865:303] Registering: CampaignQuest with key: quest
2013-07-23 10:18:11.656 otest[38865:303] Registering: CampaignQuest with key: anotherQuest
2013-07-23 10:18:11.656 otest[38865:303] Registering: CavalryMan with key: anotherKnight
2013-07-23 10:18:11.656 otest[38865:303] Registering: CavalryMan with key: yetAnotherKnight
2013-07-23 10:18:11.657 otest[38865:303] Registering: NSURL with key: serviceUrl
2013-07-23 10:18:11.657 otest[38865:303] Registering: SwordFactory with key: swordFactory
2013-07-23 10:18:11.657 otest[38865:303] Registering: Sword with key: blueSword
2013-07-23 10:18:11.658 otest[38865:303] Resource: SomeProperties.properties
2013-07-23 10:18:11.658 otest[38865:303] Attaching mutator: <TyphoonPropertyPlaceholderConfigurer: 0x100152e80>
2013-07-23 10:18:11.658 otest[38865:303] Resource: ExceptionTestAssembly.xml
2013-07-23 10:18:11.659 otest[38865:303] Registering: NSURL with key: anotherServiceUrl
2013-07-23 10:18:11.659 otest[38865:303] Registering: NSString with key: aBlaString
2013-07-23 10:18:11.660 otest[38865:303] Resource: CircularDependenciesAssembly.xml
2013-07-23 10:18:11.660 otest[38865:303] Registering: ClassADependsOnB with key: classA
2013-07-23 10:18:11.660 otest[38865:303] Registering: ClassBDependsOnA with key: classB
2013-07-23 10:18:11.661 otest[38865:303] Registering: ClassCDependsOnDAndE with key: classC
2013-07-23 10:18:11.661 otest[38865:303] Registering: ClassDDependsOnC with key: classD
2013-07-23 10:18:11.661 otest[38865:303] Registering: ClassEDependsOnC with key: classE
2013-07-23 10:18:11.662 otest[38865:303] ###### My dependencies have not yet been injected. Here's what I look like: <CampaignQuest: self.  imageUrl=(null)>
2013-07-23 10:18:11.662 otest[38865:303] Property setter invocation: <NSInvocation: 0x101d08ca0>
2013-07-23 10:18:11.663 otest[38865:303] $$$$$$$$$$$$$$$$$ My dependencies have been injected. And I know look like this: <CampaignQuest: self.  imageUrl=http://www.  appsquick.ly/theQuest.jpg>
2013-07-23 10:18:11.663 otest[38865:303] Parsing typeCode: f
2013-07-23 10:18:11.663 otest[38865:303] #################### CavalryMan before properties set
2013-07-23 10:18:11.663 otest[38865:303] Parsing typeCode: c
2013-07-23 10:18:11.664 otest[38865:303] Property setter invocation: <NSInvocation: 0x104d00a40>
2013-07-23 10:18:11.664 otest[38865:303] ############# CavalryMan after properties set
Test Case '-[TyphoonXmlComponentFactoryTests test_returns_component_from_factory_component]' passed (0.011 seconds).  

Perhaps a logging framework should be introduced? I'm most familiar with CocoaLumberjack myself, which has static, per file log levels.

[jasperblues]

I like CocoaLumberjack and I could be convinced, but my biggest criticism is that:

a) It has to be turned on manually in tests.

b) In AppCode the output from test A appears for test B - gets jumbled up.

I have another very lightweight logging framework here: https://github.com/jasperblues/OCLogTemplate

Supports:

• Various log levels - info, debug, trace
• Turning on off log levels with one compile or header flag.

I think I would prefer this one. What do you think?

[rhgills]

I agree CocoaLumberjack might be a bit overkill at the moment. We'd have to implement a new subclass of SenTestCase to enable logging in setUp and flush the logs in tearDown to fix log messages 'leaking' between tests. Not horrible but not the most elegant solution either.

Your framework should work great. The only thing missing I can think of is the ability to dynamically turn up the logging without a recompile of the library; say to get some logs from a user of a release build. At this juncture that doesn't seem worth the extra complexity to me, especially since, in my limited experience, DI failures occur at init time.

[jasperblues]

Ok. . . I could be convinced to go with CocoaLumberjack. . . but if you're convinced that OCLogTemplate is enough, let's run with that. . .

On Jul 27, 2013, at 6:23 AM, Robert Gilliam [email protected] wrote:

I agree CocoaLumberjack might be a bit overkill at the moment. We'd have to implement a new subclass of SenTestCase to enable logging in setUp and flush the logs in tearDown to fix log messages 'leaking' between tests. Not horrible but not the most elegant solution either.

Your framework should work great. The only thing missing I can think of is the ability to dynamically turn up the logging without a recompile of the library; say to get some logs from a user of a release build. At this juncture that doesn't seem worth the extra complexity to me, especially since, in my limited experience, DI failures occur at init time.

—
Reply to this email directly or view it on GitHub.

[rhgills]

OCLogTemplate it is!

[rhgills]

Fixed in 1a3bdab

[jasperblues]

Build seems to be broken. . . how is OCLogTemplate integrated? CocoaPods or sub-module?

[jasperblues]

Ah, ok - its a submodule.

[rhgills]

Sorry about that, should have mentioned as much!

[jasperblues]

No worries - its all good. . . really great work!

[rhgills]

Thanks! I'm happy that we found a simple solution to this one.

[jasperblues]

Robert, how do you turn on Typhoon's logging when you do want to see it?

[rhgills]

What I've been doing is just changing the values in OCLogTemplate.h, which is much simpler than the alternative:

If you want to use a preprocessor macro, set that either on the Typhoon static library target or the 'lowest level' cocoapods static library target linked with your target. For example, if you want logging to happen when running OS X Tests (Cocoapods), then you need to define LOGGING_LEVEL_TRACE or any other logging defines in the libPods-OS X Tests (Cocoapods)-Typhoon.a target of the Pods project.