CODEWITHSUNDEEP
iosxcodecode-coveragecoverstory
LeffelMania
LeffelMania

Reputation: 12875

iOS Code Coverage: @implementation Not Hit?

I've recently added test coverage analysis to our codebase, and thankfully the classes that I expected to be well covered are clocking in above 95% coverage. I love the ones that hit 100%, since that's obviously the goal, but a handful of my classes are stuck at 96-98%, because one line isn't being hit. That one line is the @implementation ClassName line, which I find really confusing.

Example missed implementation line

Logically if all of the class's executable lines were exercised, the class was obviously instantiated.

I'm using the standard Xcode methods (__gcov_flush()) for generating .gcda and .gcno usage data, and I'm using CoverStory for the analysis and HTML generation.

It's not a huge deal; obviously the class is well covered, but it's annoying to keep mental notes of the classes that aren't at 100% because the dang @implementation line is missed for whatever reason.

I can't find a pattern between the files that have the @implementation line hit and those that have it missed. Has anyone else experienced this and/or know what I might try to alleviate it? Could it even be a bug with CoverStory perhaps?

Upvotes: 2

Views: 508

Answers (2)

Yi Zhu
Yi Zhu

Reputation: 166

@implementation YourClass will hit while an instance of that class going to be dealloc'ed.

You can confirm that by create a empty demo class, put a checkpoint on @implementation DemoClass, and call [DemoClass new], the debugger will stop while [DemoClass .cxx_destruct] is being called, which means the instance has zero retainCount and going to be dealloc'ed.

You can also confirm that by view the code coverage html file created by XcodeCoverage; select a file, click "function" which will list all functions coverage report for that file, and you will see [DemoClass .cxx_destruct] list as a function in either green or red.

In other word, If @implementation YourClass is not being called, there is a good chance that you had retain cycles/static variables in your class implementation that prevent your class from deallocating. (e.g. contains NSURLSession object but forget to call finishTaskAndInvalidate, or contains repeat NSTimer but didn't call invalidate , or it is singleton class which contains static variables etc.)

Upvotes: 0

Chris Rutkowski
Chris Rutkowski

Reputation: 1814

I've had the same problem with my current project and you can fix it using:

Edit: For XCText, it should be XCTAssertEqualObjects since NSString * are objects

Kiwi:

[NSStringFromClass([[YourClass new] class]) should] equal:NSStringFromClass[YourClass class])]

or

XCTAssertEqualObjects(NSStringFromClass([[YourClass new] class]), NSStringFromClass([YourClass class]));

Upvotes: 3

Related Questions