Swift + Objective-C + UnitTests -> Problem

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Swift + Objective-C + UnitTests -> Problem

    Hallo,

    ich habe folgende Konstellation:

    * Swift-Framework mit Unit-Tests. Funktioniert soweit.

    * Das Swift-Framework verwendet eine statische Library die in Objective-C geschrieben ist. Das war zwar etwas Gefummel bis das lief, aber immerhin ging es: Ich musste erstmal rausfinden, das bei Frameworks das Konstrukt mit den Bridging-Headern nicht funktioniert. Stattdessen muss man die Header der zu verwendenden Objective-C-Klassen in den Umbrella-Header des Frameworks packen. Logisch, hätte ich ja gleich draufkommen können. ;(

    * So, jetzt laufen aber die Unitests nicht mehr, weil das Unit-Test-Target die Objective-C Klassen nicht kennen mag. Egal was ich importiere, Header dem Projekt hinzufüge, es geht nicht :cursing: Dabei werden die Objective-C-Klassen nur innerhalb des Frameworks verwendet, nicht explizit in den Tests.

    Hat jemand einen Tipp, was ich da wo importieren/inkludieren/build-setten muss, damit das klappt? Ewiger Dank ist der Lohn...

    Jetzt könnte man natürlich sagen: "Mensch, warum macht der Depp das Framework in Swift? Nimm doch Objective-C!" Ja, das habe ich mich auch schon gefragt, nach 1/2 Tag rumkaspern mit Buildsettings, Bridging-Headern & Co. Aber die Antwort ist, dass das Framework ein Refactoring nötig hatte und ich Swift abseits von sinnlosen "Hello-World"-Beispielen kennenlernen wollte. Die echten Probleme merkt man halt meistens in Real-Life-Beispielen. Insofern gilt, Ziel erreicht!

    ciao

    gandhi
  • Ah, Danke! Ich hatte zuerst einen Bridging-Header beim Test-Target und beim Framework. Aufgrund der Tatsache, dass es beim Framework eben nicht funktioniert hat sondern nur mit dem Umbrella-Header habe ich den B.H. auch aus dem Test-Target entfernt.

    Also, zum Mitschreiben, wenn das Problem mal wieder auftaucht:

    1. Swift-Frameworks benötigen keinen Bridging-Header um auf Objective-C zuzugreifen. Im Gegenteil das führt zu Fehlern. Benötigte Objective-C-Klassen sind im Umbrella-Header zu importieren.

    2. Das dazugehörige Unit-Testtarget hingegen braucht zwingend den Bridging-Header!

    ciao

    gandhi
  • So, um das ganze fortzuführen: Man stolpert ja von einem Problem zum nächsten, hier mal meine Liste der aktuellen Problemchen:
    1. Wenn ich in die statische Objective-C Lib eine Category einer bestehenden (NSData) Klasse hinzufüge kann ich nicht um's verrecken aus dem Swift-Framework darauf zugreifen. Versteht man das? Nein nicht wirklich. Füge ich die Category der Swift-Framework hinzu (als Objective-C Datei) geht's.
    2. Die Unit-Tests laufen nur, wenn ich die Swift-Klassen auch dem Unit-Test-Target hinzufüge. OK, damit kann ich leben. Ist halt Handarbeit. Bei der Testausführung bekomme ich dann den Fehler "Class ECRSAKey is implemented in both meinSwiftFramework and MeinSwiftFramework.xctest. One of the two will be used. Which one is undefined." Logisch, sind ja in beiden Targets. Aber anders geht's gar nicht. Versteht man das?
    3. Der SourceKit-Service crashed ständig. Und zwar seitdem die Category in den Unittests verwendet wird. Immerhin weist einem Xcode darauf hin. Anschließend geht keine Codevervollständigung mehr. Besser noch: In einigen Quelltexten geht's gar nicht mehr. Auch nach Xcode-Neustart, auch nach Rechner-Neustart. Und nein ich habe nicht das Betriebssystem neu installiert und kaufe mir auch keinen neuen Rechner.
    4. Seitdem sind in diesem Projekt die Testausführungs-Böbbel im Sourcecode-Editor verschwunden und ich kann nur noch mittels Apfel+U testen.
    Langsam macht's keinen Spaß mehr. Weniger wegen Swift sondern wegen den Unzulänglichkeiten und Bugs in Xcode 6. Man, was denke ich wehmütig an die felsenfeste Stabilität vom ProjectBuilder und Xcode 1 - 3 zurück.

    Fazit: ca. 70% der Arbeitszeit mit rumfummeln und Xcode-Bugs verbracht.

    genervter Gruß

    gandhi
  • gandhi schrieb:

    Wenn ich in die statische Objective-C Lib eine Category einer bestehenden (NSData) Klasse hinzufüge kann ich nicht um's verrecken aus dem Swift-Framework darauf zugreifen. Versteht man das? Nein nicht wirklich. Füge ich die Category der Swift-Framework hinzu (als Objective-C Datei) geht's.

    Ist das ein dynamisches oder statisches Framework? Hast Du das Testprojekt mit -ObjC oder -all_load und der statische Lib gebunden?
    „Meine Komplikation hatte eine Komplikation.“
  • Richtig.
    Verstehe ich auch nicht.

    Wenn ich die Klassen nicht dem Test Target zufüge, findet der Linker(?) sie beim ersten Testlauf nicht.
    Wenn ich dann die Klassen dem Test Target zufüge, läuft alles und ich bekomme die Meldung bezüglich der doppelten Zuordnung.
    Wenn ich die Klassen dann dem Test Target wieder entziehe, läuft alles wie gewünscht.
    +schulter zuck+

    Den Blödsinn machte Xcode 5 bereits.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Ich hatte das auch mal. Wenn ich mich recht entsinne, war das im Panel enthalten oder nicht, aber in der Targetliste nicht enthalten oder doch oder irgendwie so. Halt eine ganz normale Inkonsistenz eines Programmes, das von demjenigen zur Marktreife gebracht wurde, der sich Swift ausgedacht hat.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?