Warum verursacht die Instanziierung eines UIFont in einem iphone-Unit-Test einen Absturz?

Question

Ich versuche, einige iphone Code zu testen, die Schriftarten instanziiert. Ich habe es auf den folgenden abstürzenden Unit-Test eingegrenzt:

#import "test.h"
#import <UIKit/UIKit.h>

@implementation test

- (void)testFonts {
  [UIFont systemFontOfSize:12];
}

@end

Dies führt zu einem Absturz mit der Fehlermeldung:

Test Case '-[test testFonts]' started.
/Developer/Tools/RunPlatformUnitTests.include: line 415: 79768 Trace/BPT trap          "${THIN_TEST_RIG}" "${OTHER_TEST_FLAGS}" "${TEST_BUNDLE_PATH}"
/Developer/Tools/RunPlatformUnitTests.include:451: error: Test rig '/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.1.sdk/Developer/usr/bin/otest' exited abnormally with code 133 (it may have crashed).

Es scheint, als gäbe es einige Einstellungen, die ich in meinem Unit-Test-Target nicht vornehme, damit dies funktioniert. Wie Sie Einheit Test Dinge, die Schriftarten instanziieren?

Answer 1

Einer meiner Freunde hatte kürzlich mit diesem Problem zu kämpfen, und ich habe das letzte Projekt ausgegraben, bei dem ich dies erfolgreich eingerichtet habe. Der Trick ist, alle Ihre Tests, die UIFont in Anwendungstests, anstatt Unit-Tests zu laufen. Hier sind ein paar Dinge, die Sie beim Einrichten Ihres Anwendungstests beachten sollten:

1. BAUPHASEN: Bringen Sie Ihren Produktionscode in Ihr Testziel ein, indem Sie Ihr Hauptziel als eines der Testziele einbeziehen Abhängigkeiten einbinden, anstatt die .m-Dateien in Ihr Test Ziel. Dies dient nur der Organisation.
2. BUILD-EINSTELLUNGEN: Stellen Sie sicher, dass der "Bundle Loader" Ihres Testziels auf auf $(BUILT_PRODUCTS_DIR)/Your Product Name.app/Your Product Name Again . Beachten Sie, es ist .../Product.app/Product - Das heißt, es gibt kein .app im letzten Segment des Pfades ist. Wenn Sie neugierig sind auf die Datei zu sehen, auf die Sie sich beziehen, suchen Sie Ihr Build-Produkt, klicken Sie mit der rechten klicken Sie darauf, wählen Sie Paketinhalt anzeigen und suchen Sie dann die ausführbare Datei.
3. BUILD SETTINGS: Der "Test Host" Ihres Testziels sollte auf $(BUNDLE_LOADER) . Kinderleicht.
4. BUILD-SETTINGS: Die anderen Linker-Flags des Testziels sollten enthalten -framework SenTestingKit .
5. BUILD SETTINGS: "Test After Build" sollte Nein sein.
6. SCHEME: 'Build' sollte sowohl Ihr Testziel als auch Ihr Hauptziel enthalten Ziel enthalten, wobei in beiden Zielen nur das Feld "test" ausgewählt ist.
7. SCHEMA: 'Test' sollte nur Ihr Testziel enthalten. Die darin enthaltenen Dateien werden automatisch in die Liste aufgenommen.

... ich hoffe, das reicht, um euch alle in Schwung zu bringen. Es ist nicht alles sauber an einem Ort dokumentiert, und herauszufinden, wie man beide Arten von Tests zum Laufen bringt, hat mehr Zeit und Mühe gekostet, als ich zugeben möchte.

Es ist seltsam, dass Apple anscheinend seine eigene Dokumentation zu diesem Thema zurückgezogen hat. Ich frage mich, ob es eine weitere Änderung geben wird...

Bitte melden Sie sich bei mir, wenn Sie Ergänzungen zu den oben genannten Punkten haben. Es handelt sich nicht um eine vollständige Anleitung zum Einrichten von Anwendungstests, aber die oben genannten Punkte sind die undokumentierten Stolpersteine, auf die ich gestoßen bin. FMI, ich empfehle dringend dieser CocoaWithLove-Artikel .

Answer 2

In Apples Testing Kit werden die Unit-Tests in zwei verschiedene Kategorien unterteilt, ohne dass dies besonders deutlich wird:

• Logik-Tests

  Diese Tests überprüfen die korrekte Funktionalität Ihres Codes in einer Reinraumumgebung.

• Anwendungstests

  Diese Tests prüfen die Funktionalität Ihres Codes in einer laufenden Anwendung.

Es scheint eine Menge von UI-bezogenem Code zu geben, der nicht im "Logiktest"-Fall ausgeführt werden kann. Weitere Informationen zu Logiktests und Anwendungstests finden Sie hier.

http://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/UnitTesting/01-Unit-Test_Overview/overview.html

Answer 3

Ich habe genau dieses Problem mit 3.2 (und 3.1.3). Ich habe es in zwei verschiedenen Maschinen gesehen, so dass ich nicht glaube, dass mein SDK gebrochen ist.

Ich habe ein neues, auf der iPhone-Ansicht basierendes Projekt erstellt und einen Einheitstest und einen Testfall hinzugefügt.

Dies ist als Logiktest angelegt.

Die Konsolenausgabe sieht wie folgt aus:

Test Case '-[TestTests testTests]' started.
/Developer/Tools/RunPlatformUnitTests.include: line 415: 21141 Trace/BPT trap               "${THIN_TEST_RIG}" "${OTHER_TEST_FLAGS}" "${TEST_BUNDLE_PATH}"
/Developer/Tools/RunPlatformUnitTests.include:451: error: Test rig  '/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.1.3.sdk/Deve loper/usr/bin/otest' exited abnormally with code 133 (it may have crashed).
Command /bin/sh failed with exit code 1

Wenn ich den Unit-Test zum Debuggen einrichte, kann ich den Absturz mit dem folgenden Stacktrace sehen:

#0  0x00342d51 in __HALT 
#1  0x002947c7 in _CFRuntimeCreateInstance
#2  0x00b8441e in GSFontCreateWithName
#3  0x028c8f31 in +[UIFont systemFontOfSize:]

Ich kann sehen, Kendall's Punkt (UIKit Zeug kann nur auf dem Gerät arbeiten), aber das scheint nicht sehr gut irgendwo dokumentiert werden.

Answer 4

Haben Sie es auf dem Gerät ausprobiert? Ich glaube mich zu erinnern, dass Sie nur UIKit Zeug in Tests enthalten können, wenn auf dem Gerät ausgeführt, nicht gegen den Simulator...

Answer 5

Sorry für das Ausgraben es, aber ich habe einige Probleme mit XCT-Test auf Xcode 5 und es ist mit diesem Thread verwandt

Zitat:

"Viele UIKit-Klassen funktionieren nicht ohne die UIApplication Der Versuch, Code hinzuzufügen, um die Tests in diesem Projekt zu bestehen, ergab, dass auch andere Tests bedingt von LogicTests ausgeschlossen werden müssen:

Die standardmäßige loadView-Methode wird fehlschlagen - daher ist die testLoadView-Methode #ifdef'd out.

Jeder Versuch, ein UILabel zuzuweisen/initieren, schlägt fehl. Ich weiß nicht, warum, aber aus diesem Grund müssen alle Tests auf die Etiketten #ifdef'd sein.

Erwarten Sie im Allgemeinen nicht, dass irgendetwas aus dem UIKit-Framework in Ihren Logiktests funktioniert. Andere Frameworks werden fast immer funktionieren (in dieser Anwendung funktionieren die Frameworks CoreLocation und Foundation problemlos).

Innerhalb von UIKit werden einige Elemente funktionieren - zum Beispiel hatte UIWebView in meinen Tests keine Probleme. Welche Objekte der Benutzeroberfläche im LogicTests-Bundle (ohne eine tatsächlich laufende Anwendung) genau fehlschlagen, ist nie wirklich klar, bis Sie es versuchen, aber diese Fehler sind der Grund, warum Sie immer noch die Anwendungstests ausführen müssen, um sie zu überprüfen - die Anwendungstests sind ein zuverlässigeres Ergebnis für alles in UIKit."

URL: http://www.cocoawithlove.com/2009/12/sample-iphone-application-with-complete.html