I was doing the same type of casting for a little bit, but then I started to 
set up variables for the testing. Now I prefer to keep constants out of the 
STXXX macros and tend to write the tests like:

NSUInteger theExpectedLength = 32;
STAssertEquals(myArray.length, theExpectedLength, nil);

While in some cases it does just add an extra line, in other cases (where I 
reuse theExpectedLength), I don't have to hunt down all those magic constants 
and update them individually.

Aaron

On Aug 16, 2011, at 10:36 AM, Jens Alfke wrote:

> I’ve been using the STxxx test macros lately, as they’re the path of least 
> resistance, but I’m getting pretty frustrated with them. Worst is the way 
> that STAssertEquals is extremely picky about types (the actual and expected 
> parameters have to have exactly the same type), and worse, somehow manages to 
> defer the type checking until runtime, so you only find out when you get an 
> assertion failure.
> 
> So I keep making ‘mistakes’ like:
>       STAssertEquals(myArray.length, 32, nil);
> which compiles fine, but fails at runtime because -length returns an 
> NSUInteger and 32 is an int. Changing 32 to 32u works on 32-bit but not 
> 64-bit; the only form I’ve found that always works is the awkward
>    STAssertEquals(digest.length, (NSUInteger)32, nil);
> Not surprisingly, I still forget to do this pretty often.
> 
> The implementation of STAssertEquals is pretty gnarly so I haven’t dug into 
> why it can’t do proper type-checking. I know it’s possible to, because the 
> test macros I wrote for MYUtilities are both more lenient about types and do 
> the checking at compile-time. Is anyone considering fixing this macro, or 
> does anyone have a compatible version that works right?
> 
> —Jens_______________________________________________
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/eeyore%40monsterworks.com
> 
> This email sent to eey...@monsterworks.com
> 

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to