Bibliotheken wurden bei Verwendung von CocoaPods mit iOS-Logiktests nicht gefunden

Ich versuche, einige iOS-Logiktests für Klassen in meinem Projekt zu schreiben, die Funktionen aus einigen Bibliotheken in meiner Podspec verwenden. Ich verwende das in Xcode bereitgestellte Standard-Unit-Test-Bundle (obwohl keine Anwendungstests, sondern nur Unit-Tests).

Zum Beispiel verwende ich Magical Record und habe diese Bibliothek in meiner Podspec verlinkt. Es ist im Pods-Projekt in meinem Arbeitsbereich vorhanden und funktioniert wie erwartet, wenn die App im Simulator oder auf dem Gerät ausgeführt wird. Wenn ich versuche, das Objekt, das Magical Record verwendet, mit dem Test zu verknüpfen, wird jedoch ein Linkerfehler angezeigt, der besagt, dass die Selektoren von Magical Record nicht gefunden werden können. Ich habe versucht, mein HEADER_SEARCH_PATH in meinem Logiktest-Bundle zu aktualisieren und es sogar hart in das von CocoaPods erstellte Header-Verzeichnis zu codieren, aber kein Glück.

Ich kann problemlos Unit-Tests für Klassen ausführen, die keine CocoaPods-Bibliotheken verwenden.

Mache ich das falsch? Sollte ich etwas anderes tun, damit der Compiler die CocoaPods-Bibliotheken sieht?

CocoaPods 1.0 hat die Syntax dafür geändert. Es sieht jetzt so aus:

def shared_pods
    pod 'SSKeychain', '~> 0.1.4'
    ...
end

target 'Sail' do
    shared_pods
end

target 'Sail-iOS' do
    shared_pods
end

Pre CocoaPods 1.0 Antwort

Was Sie verwenden möchten, ist link_withvon Ihrem Podfile. Etwas wie:

link_with 'MainTarget', 'MainTargetTests'

Dann pod installwieder laufen .

Ich habe dies herausgefunden, indem ich mir angesehen habe, wie das Hauptziel meiner App darin bestand, Einstellungen von der CocoaPods-Bibliothek zu erhalten. CocoaPods enthält eine .xcconfig-Datei mit dem Namen Pods.xcconfig. Diese Datei enthält alle Header-Suchpfade.

Wenn Sie sich Ihr Projekt im Projektnavigator ansehen und auf die Registerkarte Info klicken, werden Ihre Build-Konfigurationen im oberen Bereich aufgelistet. Wenn Sie das Offenlegungsdreieck für Ihre verschiedenen Konfigurationen öffnen, werden Pods unter Ihrem Hauptziel aufgelistet. Ich musste auf das Dropdown-Menü klicken und dem logischen Testziel auch Pods hinzufügen.

Ich musste auch die Einstellungen von $(inherited)und ${PODS_HEADERS_SEARCH_PATHS}von meinem Hauptziel kopieren und sie unter Build-Einstellungen / HEADER_SEARCH_PATHS auf das logische Testziel kopieren.

Schließlich musste ich libPods.a in der Build-Phase Link Binary with Libraries für mein Ziel für Logiktests hinzufügen.

Hoffe, dies kann jemand anderem helfen.

Es gibt eine Lösung, die ich hier gefunden habe. Unit-Tests mit CocoaPods :

Öffnen Sie die Projektdatei in Xcode und wählen Sie dann das Projekt (nicht das Ziel) aus. Im rechten Bereich befindet sich ein Abschnitt namens Konfigurationen. Wählen Sie Pods in der Spalte "Basierend auf Konfigurationsdatei" für Ihr Testziel.

Ich stimme den anderen Antworten zu und sage, dass es notwendig ist, die Bibliotheken mit den Testzielen zu verknüpfen. Keiner der bisherigen Vorschläge hat mir jedoch geholfen. Wie @fabb in einem Kommentar schreibt: "Beim Testen geben isSubclassOfClass:Aufrufe NEIN zurück, wo sie JA zurückgeben sollten. Der einzige Grund, warum ich dies erklären kann, ist, dass die Abhängigkeiten wirklich sowohl mit dem Haupt- als auch mit dem Testziel verknüpft werden und wenn das Paket des Testziels Der Loader lädt das Hauptpaket und kann nicht entscheiden, welche Klasse er nehmen soll. " Ich habe das gleiche Problem mit allen vorherigen Vorschlägen in diesem Thread.

Die Lösung, die ich zur Arbeit bekam, bestand darin, meine Poddatei zu aktualisieren, um bestimmte Pods für mein Hauptziel und mein Testziel zu definieren:

target 'MyTarget' do
   pod 'AFNetworking', '~> 2.5.0'
   pod 'Mantle', '~> 1.5'
end

target 'MyTargetTests' do
   pod 'OCMockito', '~> 1.3.1'
end

Es war notwendig , einen Pod für mein Testziel anzugeben, obwohl ich keine testspezifischen Pods verwendet habe. Andernfalls würde CocoaPods nicht die erforderliche Verknüpfungslogik in mein Projekt einfügen.

Dieser Link hat mir geholfen, zu diesem Schluss zu kommen.

Ich habe hinzugefügt :exclusive => true, um doppelte Symbolfehler im Anwendungstestziel zu vermeiden.

target 'myProjectTests', :exclusive => true do
   pod 'OCMock', :head
   pod 'XCTAsyncTestCase', :git => 'https://github.com/iheartradio/xctest-additions.git'
end

link_with 'myProject', 'myProjectTests'

Wenn ich das Anwendungstestziel in das Logikeinheitstestziel geändert habe, tritt der Linkerfehler auf. Nachdem ich entfernt habe :exclusive => true, funktioniert alles wieder.

target 'myProjectTests', do
   pod 'OCMock', :head
   pod 'XCTAsyncTestCase', :git => 'https://github.com/iheartradio/xctest-additions.git'
end

link_with 'myProject', 'myProjectTests'

:exclusive => truegibt an, dass do...endNICHT alles außerhalb mit verknüpft werden sollte myProjectTests, was bei Anwendungstestzielen sinnvoll ist, aber bei logischen Testzielen Linkerfehler verursacht.

Sie können link_with gemäß der @ Keith Smiley-Lösung verwenden.

Wenn Sie gemeinsame Pods und Besonderheiten für jedes Ziel haben, können Sie die Option "def" verwenden, um eine Gruppe von Pods zu definieren. und benutze das "def" später im exklusiven Ziel.

def import_pods
    pod 'SSKeychain'
end

target 'MyProjectTests', :exclusive => true do
  import_pods
end

target 'MyProject', :exclusive => true do
  import_pods
  pod 'Typhoon'
end

Im obigen Beispiel habe ich den beiden Zielen 'SSKeychain' und 'Typhoon' nur dem Ziel 'MyProject' hinzugefügt

Meine Lösung für dieses Problem bestand darin, mein Podfile so zu ändern, dass die Bibliothek in beiden Zielen wie diesem enthalten ist

target "MyApp" do  
    pod 'GRMustache', '~> 7.0.2'
end

target "MyAppTests" do
    pod 'GRMustache', '~> 7.0.2'
end

Und da ich swift verwende, musste ich auch das Testziel so konfigurieren, dass es die MyApp-Bridging-Header.hDatei enthält. (In der Swift Compiler-Gruppe unter der Registerkarte Build Settings)

Ich hatte ein ähnliches Ereignis, als ich während einer Versionskontrolle einige Bibliotheksdateien verlor. Ich habe die Bibliotheksdatei immer noch in meinen Pods gesehen, aber da der eigentliche Code fehlt, hat XCode gesagt, dass er weg ist. Zu meiner Bestürzung brachte das Ausführen von 'pod install' die verlorenen Dateien nicht sofort zurück.

Ich musste den Pod manuell entfernen und ersetzen, indem ich Folgendes tat:

1. Entfernen Sie die Bibliothek aus der Poddatei
2. Führen Sie 'pod install' aus, um die Bibliothek vollständig zu entfernen
3. Legen Sie die Bibliothek wieder in das Podfile
4. Führen Sie 'pod install' erneut aus

Dies sollte die betreffende Bibliothek wieder in ihre ursprüngliche Form bringen.

Es ist auch erwähnenswert, dass, wenn Sie libPods.azweimal hinzugefügt haben , Sie einen bösen Fehler wie diesen erhalten:

232 duplicate symbols for architecture i386

Um dies zu beheben, löschen Sie einfach eine der libPods.aReferenzen in Ihrem Projektexplorer.

Ab CocoaPods 1.x gibt es eine neue Möglichkeit, gemeinsame Abhängigkeiten zwischen einem Ziel und dem entsprechenden Testziel zu deklarieren. Ich hatte bis jetzt die von Mark Struzinski akzeptierte Lösung verwendet, aber die Verwendung dieser Methode ergab eine große Anzahl von Warnungen, als ich meine Tests ausführte, die:

Class SomeClass is implemented in both /Path/To/Test/Target and /Path/To/App/Target. One of the two will be used. Which one is undefined.

Mit CocoaPods 1.x können wir unser -Test-Ziel über die Suchpfade des übergeordneten Ziels als erben deklarieren, wie folgt:

target 'MyApp' do
    pod 'aPod'
    pod 'anotherPod'
    project 'MyApp.xcodeproj'
end
target 'MyAppTests' do
    inherit! :search_paths
    project 'MyApp.xcodeproj'
end

Dies führt dazu, dass das -Test-Ziel ohne mehrere binäre Kopien Zugriff auf die Abhängigkeiten des App-Ziels hat. Dies hat die Testaufbauzeiten für mich erheblich verkürzt.

Versuchen Sie das, es funktioniert für mich,

Wir müssen Pods in Konfigurationen setzen,

Die Projekt-> Info-> Konfigurationen im Xcode-Projekt (Ihr Projekt) sollten für Debug, Release (und was Sie sonst noch haben) auf das Hauptprojekt 'Pods' eingestellt sein. Siehe "Header nicht gefunden - Suchpfade nicht enthalten"

Hoffe das ist Hilfe für jemanden.

Ich arbeite mit der GoogleMaps Objective-C POD-Integration unter iOS mit meiner Swift-App. Für mich bestand das Problem darin, dass das Testziel keinen Verweis auf die Bridge-Header-Datei ( SWIFT_OBJC_BRIDGING_HEADER ) in den Build-Einstellungen hatte. Stellen Sie sicher, dass sowohl Ihre App- als auch Ihre Test-App-Ziele darauf verweisen, damit die API-Aufrufe von Drittanbietern (Karten-API usw.) in schnellen Komponententests verwendet werden können.

Die nächste Syntax liefert für mich das beste Ergebnis (getestet unter cocoapod v.1.2.1):

https://github.com/CocoaPods/CocoaPods/issues/4626#issuecomment-210402349

 target 'App' do
    pod 'GoogleAnalytics' , '~> 3.0'
    pod 'GoogleTagManager' , '~> 3.0'

     pod 'SDWebImage', '~>3.7'
     platform :ios, '8.0'
     use_frameworks!

     target 'App Unit Tests' do
         inherit! :search_paths
     end
 end

Ohne dies habe ich während des Testlaufs Warnungen über doppelte Symbole.

Danach verschwanden die Warnungen.

Ich hatte Probleme mit OpenCV unter XCTest. Es gab mir Linker-Fehler Undefined symbols for architecture arm64für Klassen wie cv::Mat. Ich installiere OpenCV über CocoaPods pod 'OpenCV', '~> 2.0'unter dem Hauptziel. Egal wie sehr ich versucht habe, die OpenCV-Abhängigkeit unter das Testziel zu stellen oder inherit! :search_pathsnichts davon zu verwenden, hat funktioniert. Die Lösung bestand darin, ein abstract_targetähnliches zu erstellen :

# Uncomment the next line to define a global platform for your project
platform :ios, '6.1.6'

abstract_target 'Shows' do
  pod 'RMVision', path: '../..'
  pod 'RMShared', path: '../../../RMShared'
  pod 'OpenCV', '~> 2.0'

  target 'RMVisionSample' do
    # Uncomment the next line if you're using Swift or would like to use dynamic frameworks
    # use_frameworks!

    # Pods for RMVisionSample
  end

  target 'RMVisionSampleTests' do
    # inherit! :search_paths
    # Pods for testing
  end

  target 'RMVisionBenchmarks' do
    # inherit! :search_paths
    # Pods for testing
  end

end 

Ebenfalls nützlich sind die Befehle pod deintegrate& pod clean, mit denen Sie das Projekt bereinigen und sicherstellen können, dass Sie beim Testen neu beginnen. Sie können diese beiden mit installieren [sudo] gem install cocoapods-deintegrate cocoapods-clean.