XCTAssertEqual Fehler: ("3") ist nicht gleich ("3")

NSMutableArray *arr = [NSMutableArray array];
[arr addObject:@"1"];
[arr addObject:@"2"];
[arr addObject:@"3"];

//This statement is fine.
XCTAssertTrue(arr.count == 3, @"Wrong array size.");

//This assertion fails with an error: ((arr.count) equal to (3)) failed: ("3") is not equal to ("3")
XCTAssertEqual(arr.count, 3, @"Wrong array size.");

Was ich nicht verstehe, über XCTAssertEqual? Warum hat die Letzte Behauptung nicht?

InformationsquelleAutor der Frage Sergey | 2013-10-04

  1. 47

    Ich hatte auch ziemliche Probleme mit der Xcode-5-tests. Es scheint noch ziemlich buggy mit einigen seltsamen Verhalten - allerdings habe ich die definitive Grund Ihrer besonderen XCTAssertEqual funktioniert nicht.

    Wenn wir einen Blick auf den test-code, den wir sehen es eigentlich die folgende (entnommen direkt aus XCTestsAssertionsImpl.h - es kann einfacher sein, zu sehen):

    #define _XCTPrimitiveAssertEqual(a1, a2, format...) \
({ \
    @try { \
        __typeof__(a1) a1value = (a1); \
        __typeof__(a2) a2value = (a2); \
        NSValue *a1encoded = [NSValue value:&a1value withObjCType:@encode(__typeof__(a1))]; \
        NSValue *a2encoded = [NSValue value:&a2value withObjCType:@encode(__typeof__(a2))]; \
        float aNaN = NAN; \
        NSValue *aNaNencoded = [NSValue value:&aNaN withObjCType:@encode(__typeof__(aNaN))]; \
        if ([a1encoded isEqualToValue:aNaNencoded] || [a2encoded isEqualToValue:aNaNencoded] || ![a1encoded isEqualToValue:a2encoded]) { \
                _XCTRegisterFailure(_XCTFailureDescription(_XCTAssertion_Equal, 0, @#a1, @#a2, _XCTDescriptionForValue(a1encoded), _XCTDescriptionForValue(a2encoded)),format); \
        } \
    } \
    @catch (id exception) { \
        _XCTRegisterFailure(_XCTFailureDescription(_XCTAssertion_Equal, 1, @#a1, @#a2, [exception reason]),format); \
    }\
})

    Hier ist das problem:

    Was der test tatsächlich tun wird, die Codierung der Werte in eine NSValue und dann vergleichen. "Okay", werden Sie sagen, "aber was ist das problem?" Ich glaube nicht, es war ein, bis ich meinen eigenen test-Fall für Sie. Das problem ist, dass NSValue ist -isEqualToValue muss auch vergleichen Sie die NSValue ist Codierung sowie den tatsächlichen Wert. Beide muss gleich für die Methode zurück YES.

    In deinem Fall arr.count ist ein NSUInteger ist ein typedef von unsigned int. Der compile-Zeit-Konstante 3 vermutlich artet signed int zur Laufzeit. Also, wenn die beiden setzen sich in ein NSValue Objekt, Ihre encoding-Typen nicht gleich sind und somit die beiden NICHT gleich nach -[NSValue isEqualToValue].

    Können Sie beweisen dies mit einem custom-Beispiel. Der folgende code explizit macht genau das, was XCTAssertEqual:

    //Note explicit types
unsigned int a1 = 3;
signed int a2 = 3;

__typeof__(a1) a1value = (a1);
__typeof__(a2) a2value = (a2);

NSValue *a1encoded = [NSValue value:&a1value withObjCType:@encode(__typeof__(a1))];
NSValue *a2encoded = [NSValue value:&a2value withObjCType:@encode(__typeof__(a2))];

if (![a1encoded isEqualToValue:a2encoded]) {
    NSLog(@"3 != 3 :(");
}

    "3 != 3 :(" erscheint im log jedes mal.

    Ich beeile mich hinzuzufügen, dass dies in der Tat zu erwartende Verhalten. NSValue ist soll zu überprüfen, die Art der Codierung, wenn dabei Vergleiche. Es ist halt leider nicht das, was wir erwartet hatten beim testen zwei ('equal') Ganzzahlen.

    XCTAssertTruehat übrigens viel einfacher Logik, und verhält sich im Allgemeinen wie erwartet (wieder, siehe die eigentliche Quelle dafür, wie es bestimmt, ob die assertion fehlschlägt).

    InformationsquelleAutor der Antwort Ephemera

  2. 5

    Hatte ich dieses problem auch. @Ephemera und @napier angegeben, dies ist eine Typ Problem.

    Kann es gelöst werden, indem Sie einen Wert des richtigen Typs, mit dem c-literal Modifikatoren.

    XCTAssertEqual(arr.count, 3ul, @"Wrong array size.");

    Finden Sie die richtige Art von sucht, bis Sie den Rückgabetyp der Funktion auf der linken Seite - ALT-click auf arr.count:

    - (NSUInteger)count;

    Nun ALT-klicken Sie auf NSUInteger finden Sie Ihren Typ: 

    typedef unsigned long NSUInteger;

    Nun die c-literal numerisches format für unsigned long - google ist ein guter Freund, aber diese Seite funktioniert:

    http://www.tutorialspoint.com/cprogramming/c_constants.htm

    Als quick-Tipp hier ist, müssen Sie möglicherweise die Verwendung von U (unsigned) L (lang) oder F (float), und stellen Sie sicher, Sie schreiben 1.0 statt 1 um eine doppelte. Kleinbuchstaben funktioniert auch, wie in meinem Beispiel oben.

    InformationsquelleAutor der Antwort Alex Brown

  3. 3

    Den Fall, dass jemand anderes auf der Suche nach dem Problem führen von Doppel-Vergleich wie mich (die Lösung oben funktioniert nicht für Schwimmer & doppelt), versuchen:

    XCTAssertEqualWithAccuracy(number.doubleValue, 12.34, 0.01);

    Generiert einen Fehler, wenn Sie (Unterschied zwischen (\a expression1) und (\a Ausdruck2) ist > (\a Genauigkeit))).

    InformationsquelleAutor der Antwort Kjuly

  4. 0

    Eine alternative ist, um Sie nur casting:

    XCTAssertEqual(arr.count, (NSUInteger)3, @"Wrong array size.");

    Es ist die beste Lösung mit dem aktuellen Zustand der Werkzeuge, vor allem, wenn Sie code haben wo Sie sind mit XCTAssertEqual viel und nicht wechseln wollen, zu XCTAssertTrue.

    (Ich bemerkte, @RobNapier diesen Vorschlag machte in einem Kommentar.)

    InformationsquelleAutor der Antwort ThomasW

  5. 0

    Bekam ich hat von diesem Problem auch sehr dankbar für die workarounds, die hier bereitgestellt werden.
    Schnelle FYI, es scheint, dass das gefixt wurde Xcode 5.1 Version.

    https://developer.apple.com/library/mac/releasenotes/DeveloperTools/RN-Xcode/xc5_release_notes/xc5_release_notes.html

    Den XCTAssertEqual makro (ehemals STAssertEquals mit OCUnit) richtig vergleicht Skalare Werte von verschiedenen Typen, ohne casting, zum Beispiel int und NSInteger. Es können nicht mehr akzeptieren, nicht Skalare Typen, wie Strukturen, zum Vergleich. (14435933)

    Habe ich noch nicht aktualisiert von Xcode 5.0.2 aber mein Kollege hat, und das gleiche XC-tests, die zuvor nicht wegen diesem problem sind nun vorbei, ohne das casting Abhilfe.

    InformationsquelleAutor der Antwort Todd Patterson

Schreibe einen Kommentar