should equal throws exception when comparing const pointer to a non-const pointer about cedar HOT 5 CLOSED

from cedar.

Thanks for your message!

I looked further and see that the exception for the test example I referenced is in the beforeEach block for the test. The exception occurs when the bold line below is executed:

    describe(@"#drawRect2:", ^{
        __block UIBezierPath *fakePath;
        __block CGRect passedRect;
        __block Swizzlean *bezierSwizz;
        __block struct CGPath *path;
        
        beforeEach(^{
            fakePath = nice_fake_for([UIBezierPath class]);
            
            bezierSwizz = [[Swizzlean alloc] initWithClassToSwizzle:[UIBezierPath class]];
            [bezierSwizz swizzleClassMethod:@selector(bezierPathWithRect:) withReplacementImplementation:^(id self, CGRect rect) {
                passedRect = rect;
                return [fakePath retain];
            }];
            
            path = CGPathCreateMutable();
            fakePath stub_method(@selector(CGPath)).and_return(path);
            
            view.bounds = CGRectMake(0,0,200,200);
            [view drawRect:CGRectZero];
        });
        
        afterEach(^{
            [bezierSwizz resetSwizzledClassMethod];
        });
        
        fit(@"sets the shadow color", ^{
            view.layer.shadowColor should equal([UIColor blackColor].CGColor);
        });
        
    });

If I add a const specifier to the declaration for path, the exception goes away.

__block const struct CGPath *path;

Thanks again for your help!

from cedar.

The invalid return type message sounds really similar to the error messages for Cedar's fakes.

My guess is that you have a fake that returns a CGPath * but the UIKit api now returns a const CGPath *.

What's happening under the hood is that Cedar's fakes try to verify that your stubbed values are correct - it wants to catch errors about mismatched return types early, so that you aren't surprised when your tests are wrong. Perhaps as part of building up your subview, or the label, there's a fake somewhere that's providing a CGPath?

That's all just my intuition, but if I'm wrong, I'd try tracking down the "invalid return value type" message, set the appropriate breakpoint in Cedar and try to walk back up the call stack and understand how that happened.

from cedar.

Oh sorry @markcarl I didn't see your response, I'm glad you got it to work again. Just a few thoughts and kind words of advice:

• Don't make fakes for UIBezierPath -- you don't own that API and apple can change it. Those tests will be brittle and break again in the future.
• In general, try not to make fakes for value types like bezier paths, arrays or dictionaries

Only mentioning that because I've been bit by that a dozen times before personally, and it's always a tough issue to troubleshoot.

from cedar.

Closing now as resolved, but feel free to re-open if you'd like to discuss it more. Always happy to talk to Cedar users :)

from cedar.