2

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?

LeffelMania
  • 12,765
  • 4
  • 32
  • 34
  • Could it be a bug in the code coverage tool? Check out its known issues. – Dandré Mar 14 '14 at 05:28
  • Verified that it's not a bug in CoverStory. The same line appears missed when analyzing with the `gcovr` python tool. It seems it's either a bug in the coverage data gathering at runtime, or there's something about my unit tests causing this. – LeffelMania Mar 14 '14 at 06:24
  • The `@implementation` line is a declaration and does not generate own code, it only determine how the following lines are interpreted. Thus, it should never been "executed". – Matthias Mar 14 '14 at 07:19
  • I definitely agree with that; I'm trying to figure out why it's hit in some files but missed in others. Missing the 100% mark because a declaration line is processed as executable and missed is annoying. – LeffelMania Mar 14 '14 at 17:52
  • Did you ever find out what the deal was? I'm having the same `0 @implementation` issue, using Jon Reid's [XcodeCoverage](https://github.com/jonreid/XcodeCoverage) setup. – epologee Apr 15 '14 at 08:28
  • Nope, I've received/discovered no additional information on this. Stumped. – LeffelMania Apr 15 '14 at 17:54
  • Same here. Using XcodeCoverage and this line is not being run. – Ethan Mick Jun 12 '14 at 14:24

2 Answers2

3

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]));
Craig Trader
  • 15,507
  • 6
  • 37
  • 55
Chris Rutkowski
  • 1,774
  • 1
  • 26
  • 36
0

@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.)

Yi Zhu
  • 166
  • 8