and NSNumberFormatter

Being good developers we Unit Test almost everything at my current job. Today a colleague of mine had a pretty interesting issue testing NSNumberFormatter output.

The initial test looked like the following:

The implementation was similar to:

But alas! Xcode complained.

XCTAssertEqual failed: (“Optional(“9,99 €”)”) is not equal to (“Optional(“9,99 €”)”)

After trying several different variants for the assertion (including XCTAssertTrue, etc.), we added a small helper extension to visualize the actual string content.

Outputting the value of both the expected and the formatted string gave the following.

# Formatted string
Optional([51, 57, 44, 57, 57, 194, 160, 226, 130, 172])
# Expected string
Optional([51, 57, 44, 57, 57, 32, 226, 130, 172])

The smart reader will spot the difference. The string returned by the NSNumberFormatter contains a non-breaking space (U+00A0) between the amount and the currency sign (194, 160 in the byte array), whereas the string we expected only contains a regular space (U+0020, or 32 in the byte array).


If your string comparison fails, always also check the non-visible characters.


Actually String already contains a method to get the UTF-8 Code Units. It’s nulTerminatedUTF8 or Array(“string”.utf8).

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.