Escape sequences in STAssertEqualStrings

Question

I'm writing a discovery test against the Cocoa API as I ramp up on all things Mac related. I'm currently trying to discover the best method for URL encoding a string. Using the Google toolbox for Mac I have a unit test that I intentionally cause a failure in:

 NSString* expected = @"ab%%20c";
 NSString* encoded = @"ab c";
 STAssertEqualStrings(expected, encoded, @"Expected [%s] actual [%s]", [expected UTF8String], [encoded UTF8String]);

and it complains "ab P != ab c" The garbage it dumps in the output is throwing me. It's as if the percent sign isn't properly escaped but I know it is. My main question is how do I get a properly formed error message so I can be sure I'm dealing with apples instead of oranges?

*update Stackoverflow was removing the garbage in my original post. The above failure is intentional to illustrate a problem with the failure message. I'm concerned with the garbage that shows in the failure message as it does cleanly not detail what's in the actual string. The failure says something like "assertion failed ab[apple-symbol]c != ab c" where I get an apple character in the message instead of a percent sign. In practice encoded would be the return of a method call and I'd like to inspect, using the assertion failure message, the contents of the string.

Answer 1

You’re confusing backslash escaping, which is applied at compile time, with percent-sign escaping, which is applied to format string by printf-like functions and methods. Since expected isn’t being processed by such a function, the percent signs are not escaping anything.

That said, unless StackOverflow is mangling your message, the percent signs should be present in “ab%%c != ab c”.

Answer 2

Yes Stackoverflow was misinterpreting my question. There's garbage showing in the assertion failure. More important, could you elaborate on the difference between blackslash compile-time and runtime percent escaping? I tried just backslash escaping the percent sign but that doesn't give me what I want. Could you post an example that would result in an assertion failure that echose the actual contents of the string? Is it a limitation of the unit testing framework? I currently have a test that does what I want, but when it breaks it's near impossible to determine what the object under test is inserting into the result.