Nie znaleziono bibliotek podczas używania CocoaPods z testami logiki systemu iOS

Próbuję napisać kilka testów logicznych iOS dla klas w moim projekcie, które używają funkcjonalności z niektórych bibliotek w moim podspec. Używam standardowego pakietu testów jednostkowych dostarczonego w Xcode (chociaż nie testów aplikacji, tylko testy jednostkowe).

Na przykład używam Magical Record i mam tę bibliotekę połączoną w moim podspec. Jest obecny w projekcie Pods w moim obszarze roboczym i działa zgodnie z oczekiwaniami, gdy aplikacja jest uruchomiona w symulatorze lub na urządzeniu. Kiedy jednak próbuję połączyć z testem obiekt, który używa Magical Record, pojawia się błąd linkera informujący, że nie może znaleźć selektorów z Magical Record. Próbowałem zaktualizować ścieżkę HEADER_SEARCH_PATH w moim pakiecie testowania logiki, nawet mocno zakodowałem ją w katalogu nagłówków utworzonym przez CocoaPods, ale bez powodzenia.

Mogę bez problemu przeprowadzić testy jednostkowe dla klas, które nie używają bibliotek CocoaPods.

Czy robię to źle? Czy powinienem zrobić coś innego, aby kompilator mógł zobaczyć biblioteki CocoaPods?

CocoaPods 1.0 zmieniła składnię tego. Teraz wygląda to tak:

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

target 'Sail' do
    shared_pods
end

target 'Sail-iOS' do
    shared_pods
end

Odpowiedź sprzed wersji CocoaPods 1.0

To, czego chcesz użyć, pochodzi link_withz twojego Podfile. Coś jak:

link_with 'MainTarget', 'MainTargetTests'

Następnie biegnij pod installponownie.

Zrozumiałem to, sprawdzając, jak głównym celem mojej aplikacji było odbieranie ustawień z biblioteki CocoaPods. CocoaPods zawiera plik .xcconfig o nazwie Pods.xcconfig. Ten plik zawiera wszystkie ścieżki wyszukiwania nagłówków.

Jeśli spojrzysz na swój projekt w nawigatorze projektów i klikniesz kartę Informacje, w górnej sekcji zobaczysz konfiguracje kompilacji. Jeśli otworzysz trójkąt ujawniania dla różnych konfiguracji, zobaczysz pody wymienione pod głównym celem. Musiałem kliknąć menu i dodać pody do celu testu logicznego.

Miałem też skopiować ustawienia $(inherited)i ${PODS_HEADERS_SEARCH_PATHS}od mojego głównego celu i skopiować je do celu testu logika obszarze Ustawienia Build / HEADER_SEARCH_PATHS.

Na koniec musiałem dodać libPods.a w fazie kompilacji Link Binary with Libraries dla mojego celu testów logicznych.

Mam nadzieję, że to może pomóc komuś innemu.

Jest rozwiązanie, które znalazłem tutaj Testy jednostkowe z CocoaPods :

Otwórz plik projektu w Xcode, a następnie wybierz projekt (nie cel), w prawym panelu znajduje się sekcja o nazwie Konfiguracje. Wybierz Pods w kolumnie „Na podstawie pliku konfiguracyjnego” dla celu testowego.

Zgadzam się z innymi odpowiedziami, mówiąc, że konieczne jest powiązanie bibliotek z celami testowymi. Jednak żadna z dotychczasowych sugestii nie pomogła mi. Jak pisze @fabb w komentarzu: „podczas testowania isSubclassOfClass:wywołania zwracają NIE, a powinny zwracać TAK. Jedynym powodem, dla którego mogę to wyjaśnić, jest to, że zależności są naprawdę połączone zarówno z głównym, jak i testowym celem, a także gdy pakiet celu testowego loader ładuje główny pakiet, nie może zdecydować, którą klasę wybrać. " Mam ten sam problem ze wszystkimi poprzednimi sugestiami w tym wątku.

Rozwiązaniem, które dostałem do pracy, było zaktualizowanie mojego pliku Podfile, aby zdefiniować określone pody dla mojego głównego celu i celu testowego:

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

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

Było to konieczne , aby określić POD dla mojego cel testu, mimo że nie używaliśmy żadnych testów konkretnych strąków. W przeciwnym razie CocoaPods nie wstawiłby niezbędnej logiki łączenia w moim projekcie.

Ten link pomógł mi dojść do takiego wniosku.

Dodałem, :exclusive => trueaby uniknąć zduplikowanych błędów symboli w celu testu aplikacji.

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

link_with 'myProject', 'myProjectTests'

Kiedy zmieniłem cel testu aplikacji na test jednostki logicznej, pojawia się błąd konsolidatora. Po usunięciu :exclusive => truewszystko znów działa.

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

link_with 'myProject', 'myProjectTests'

:exclusive => truestwierdza, że ​​wszystko na zewnątrz do...endNIE powinno być powiązane myProjectTests, co jest rozsądne w przypadku celów testów aplikacji, ale spowoduje błędy konsolidatora w celach testów logicznych.

Możesz użyć link_with zgodnie z rozwiązaniem @Keith Smiley.

Jeśli masz wspólne pody i specyfikacje dla każdego celu, możesz użyć opcji „def”, aby zdefiniować grupę podów. i użyj "def" później w wyłącznym celu.

def import_pods
    pod 'SSKeychain'
end

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

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

w powyższym przykładzie dodałem „SSKeychain” do obu celów, a „Typhoon” tylko do celu „MyProject”

Moim rozwiązaniem tego problemu była zmiana mojego pliku Podfile, aby włączyć bibliotekę do obu celów, takich jak ten

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

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

A ponieważ używam swift, musiałem również skonfigurować cel testowy, aby uwzględnić MyApp-Bridging-Header.hplik. (W grupie Swift Compiler na karcie Ustawienia kompilacji)

Miałem podobne zdarzenie, gdy zgubiłem niektóre pliki biblioteczne podczas kontroli wersji. Nadal widziałem plik biblioteki w moich Podach, ale z brakującym kodem XCode powiedział, że zniknął. Ku mojemu przerażeniu uruchomienie „instalacji pod” nie przywróciło od razu utraconych plików.

Musiałem ręcznie usunąć i wymienić kapsułę, wykonując następujące czynności:

1. Usuń bibliotekę z pliku Podfile
2. Uruchom „pod install”, aby całkowicie usunąć bibliotekę
3. Umieść bibliotekę z powrotem w Podfile
4. Uruchom ponownie „pod install”

Powinno to przywrócić daną bibliotekę do jej pierwotnej formy.

Warto również zauważyć, że jeśli libPods.adodałeś dwa razy, pojawi się taki nieprzyjemny błąd:

232 duplicate symbols for architecture i386

Aby to naprawić, po prostu usuń jedno z libPods.aodniesień w Eksploratorze projektów.

Począwszy od CocoaPods 1.x, istnieje nowy sposób deklarowania współdzielonych zależności między celem a odpowiadającym mu celem testowym. Do tej pory korzystałem z przyjętego rozwiązania Marka Struzińskiego, ale użycie tej metody przyniosło ogromną liczbę ostrzeżeń podczas przeprowadzania moich testów, które:

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.

Dzięki CocoaPods 1.x możemy zadeklarować nasz cel -Test jako dziedziczący poprzez ścieżki wyszukiwania celu nadrzędnego, na przykład:

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

Spowoduje to, że obiekt docelowy -Test będzie miał dostęp do zależności celu aplikacji bez wielu kopii binarnych. To znacznie przyspieszyło czas tworzenia testów.

Spróbuj, to działa dla mnie,

Musimy ustawić pody w konfiguracjach,

Projekt-> Informacje-> Konfiguracje w projekcie Xcode (Twoim projekcie) powinny być ustawione na „Pods” głównego projektu dla debugowania, wydania (i tego, co jeszcze masz). Zobacz „Nie znaleziono nagłówków - nie uwzględniono ścieżek wyszukiwania”

Mam nadzieję, że to komuś pomoże.

Pracuję z integracją GoogleMaps Objective-C POD na iOS z moją aplikacją Swift, więc problem polegał na tym, że cel testowy nie miał odniesienia do pliku nagłówkowego mostka ( SWIFT_OBJC_BRIDGING_HEADER ) w ustawieniach kompilacji. Upewnij się, że zarówno aplikacja, jak i cele aplikacji testowej wskazują na to, aby wywołania interfejsu API innej firmy (interfejs API map itp.) Mogły być używane w szybkich testach jednostkowych.

Następna składnia daje najlepszy wynik dla mnie (testowane pod 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

Bez tego mam ostrzeżenia podczas testu o zduplikowanych symbolach.

Po tym ostrzeżenia zniknęły.

Miałem problemy z używaniem OpenCV pod XCTest. To dawało mi błędy linkera Undefined symbols for architecture arm64dla klas takich jak cv::Mat. Instaluję OpenCV przez CocoaPods, używając pod 'OpenCV', '~> 2.0'głównego celu. Bez względu na to, jak bardzo starałem się umieścić zależność OpenCV pod celem testowym lub inherit! :search_pathsnic z tego nie zadziałało. Rozwiązaniem było stworzenie abstract_targettakiego:

# 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 

Przydatne są również polecenia pod deintegrate& pod clean, które pomagają oczyścić projekt i upewnić się, że zaczynasz od nowa podczas testowania. Możesz zainstalować te dwa za pomocą [sudo] gem install cocoapods-deintegrate cocoapods-clean.