views:

89

answers:

1

I've been building a framework and writing unit tests in GHUnit. One of my Framework's accessor methods returns an NSInteger.

I assert the expected value in the tests like this:

GHAssertEquals(1320, request.port, @"Port number should be 1320");

When running my tests with an AppKit UI based frontend this assertion passes.

However, when I run my tests on the command line, it fails with a type-mismatch unless I type-cast my hard-coded 1320 as (NSInteger). What's causing the difference in the way the integer is being interpreted by the compiler? Is xcodebuild on the command line using a different data-type for hard coded integers?

+2  A: 

Are you building your applications for different architectures (perhaps because one is building universal and one is building for one architecture)? NSInteger builds as 32-bit or 64-bit depending on the target architecture (src), which may differ from what the compiler chooses for a small constant. The cast certainly makes your intentions clear.

kevingessner
The compiler will choose `int` for a constant equal to 1320. It is a decimal constant, has no suffix, and fits within the minimum specified range for `int`.
dreamlax
You're right! I was building a universal binary from within Xcode. My tests are less fragile if I'm explicit about the data-types in any case so it was a good find :)
d11wtq