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