Bibliotecas que no se encuentran al usar CocoaPods con pruebas lógicas de iOS

Estoy tratando de escribir algunas pruebas de lógica de iOS en las clases de mi proyecto que utilizan la funcionalidad de algunas de las bibliotecas de mi podspec. Estoy usando el paquete de prueba de unidad estándar provisto en Xcode (aunque no Pruebas de aplicación, solo Pruebas de unidad).

Por ejemplo, uso Magical Record y tengo esa biblioteca vinculada en mi podspec. Está presente en el proyecto Pods en mi espacio de trabajo y funciona como se esperaba cuando la aplicación se ejecuta en el simulador o en el dispositivo. Sin embargo, cuando intento vincular a la prueba el objeto que usa el Registro Mágico, aparece un error de enlace que indica que no puede encontrar los selectores del Registro Mágico. Intenté actualizar mi HEADER_SEARCH_PATH en mi paquete de pruebas lógicas, incluso codificándolo en el directorio de encabezados creado por CocoaPods, pero no tuve suerte.

Puedo ejecutar pruebas unitarias contra clases que no usan bibliotecas CocoaPods sin ningún problema.

¿Voy por esto mal? ¿Debería hacer algo más para que el compilador vea las bibliotecas de CocoaPods?

CocoaPods 1.0 ha cambiado la sintaxis para esto. Ahora se ve así:

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 respuesta

Lo que quieres usar es link_withde tu Podfile. Algo como:

link_with 'MainTarget', 'MainTargetTests'

Luego corre de pod installnuevo.

Descubrí esto al observar cómo el objetivo principal de mi aplicación estaba recibiendo configuraciones de la biblioteca CocoaPods. CocoaPods incluye un archivo .xcconfig llamado Pods.xcconfig. Este archivo contiene todas las rutas de búsqueda de encabezado.

Si observa su proyecto en el navegador de proyectos y hace clic en la pestaña Información, verá sus configuraciones de compilación en la sección superior. Si abre el triángulo de revelación para sus diferentes configuraciones, verá Pods enumerados debajo de su objetivo principal. Tuve que hacer clic en el menú desplegable y agregar Pods al objetivo de prueba lógica también.

También tuve que copiar la configuración de $(inherited)y ${PODS_HEADERS_SEARCH_PATHS}desde mi objetivo principal y copiarla al objetivo de prueba lógica en Configuración de compilación / HEADER_SEARCH_PATHS.

Finalmente, tuve que agregar libPods.a en la fase de compilación Enlace binario con bibliotecas para mi objetivo de pruebas lógicas.

Espero que esto pueda ayudar a alguien más.

Hay una solución que encontré aquí Pruebas unitarias con CocoaPods :

Abra el archivo del proyecto en Xcode, luego elija el Proyecto (no el objetivo), en el panel derecho, hay una sección llamada Configuraciones. Elija Pods en la columna "Basado en el archivo de configuración" para su objetivo de prueba.

Estoy de acuerdo con las otras respuestas que dicen que es necesario vincular las bibliotecas a los objetivos de prueba. Sin embargo, ninguna de las sugerencias hasta ahora me ayudó. Como @fabb escribe en un comentario: "al probar, las isSubclassOfClass:llamadas devuelven NO donde deberían devolver SÍ. La única razón por la que puedo explicar esto es que las dependencias realmente se vinculan tanto al objetivo principal como al objetivo de prueba, y cuando el paquete del objetivo de prueba el cargador carga el paquete principal, no puede decidir qué clase tomar ". Me sale el mismo problema con todas las sugerencias anteriores en este hilo.

La solución que me puse a trabajar fue actualizar mi Podfile para definir Pods específicos para mi objetivo principal y mi objetivo de prueba:

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

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

Era necesario especificar un Pod para mi objetivo de prueba aunque no utilicé ningún Pod específico de prueba. De lo contrario, CocoaPods no insertaría la lógica de enlace necesaria en mi proyecto.

Este enlace es lo que me ayudó a llegar a esta conclusión.

Agregué :exclusive => truepara evitar errores de símbolos duplicados en el objetivo de prueba de la aplicación.

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

link_with 'myProject', 'myProjectTests'

Cuando cambié el objetivo de prueba de la aplicación a la prueba de unidad lógica, se produce el error del vinculador. Después de eliminar :exclusive => true, todo funciona de nuevo.

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

link_with 'myProject', 'myProjectTests'

:exclusive => trueestablece que todo lo externo do...endNO debe estar vinculado a myProjectTests, lo cual es razonable en los objetivos de prueba de la aplicación, pero causará errores de enlazador en los objetivos de prueba lógica.

Puede usar link_with de acuerdo con la solución @Keith Smiley.

En caso de que tenga pods comunes y detalles específicos para cada objetivo, es posible que desee utilizar la opción "def" para definir un grupo de pods. y usa el "def" más tarde en objetivo exclusivo.

def import_pods
    pod 'SSKeychain'
end

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

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

en el ejemplo anterior, agregué 'SSKeychain' a ambos objetivos, y 'Typhoon' solo al objetivo 'MyProject'

Mi solución a este problema fue cambiar mi Podfile para incluir la biblioteca en ambos objetivos como este

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

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

Y como estoy usando Swift, también tuve que configurar el objetivo de prueba para incluir el MyApp-Bridging-Header.harchivo. (En el grupo Compilador rápido en la pestaña Configuración de compilación)

Tuve una ocurrencia similar cuando perdí algunos archivos de la biblioteca durante algún control de versión. Todavía vi el archivo de la biblioteca en mis Pods, pero al faltar el código real, XCode dijo que se había ido. Para mi consternación, ejecutar 'pod install' no devolvió de inmediato los archivos perdidos.

Tuve que quitar y reemplazar el pod manualmente haciendo lo siguiente:

1. Eliminar la biblioteca del Podfile
2. Ejecute 'pod install' para eliminar la biblioteca por completo
3. Vuelva a colocar la biblioteca en el Podfile.
4. Ejecute 'pod install' nuevamente

Esto debería volver a poner la biblioteca en cuestión en su forma original.

También vale la pena señalar que si ha libPods.aagregado dos veces, obtendrá un error desagradable como este:

232 duplicate symbols for architecture i386

Para solucionarlo, simplemente elimine una de las libPods.areferencias en su Explorador de proyectos.

A partir de CocoaPods 1.x, hay una nueva forma de declarar dependencias compartidas entre un objetivo y el objetivo de prueba correspondiente. Había estado usando la solución aceptada por Mark Struzinski hasta este punto, pero el uso de este método arrojó una gran cantidad de advertencias al ejecutar mis pruebas que:

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.

Con CocoaPods 1.x podemos declarar nuestro objetivo de prueba como heredado a través de las rutas de búsqueda del objetivo principal, de esta manera:

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

Esto dará como resultado que el objetivo de prueba tenga acceso a las dependencias del objetivo de la aplicación, sin múltiples copias binarias. Esto me ha acelerado seriamente los tiempos de construcción de prueba.

Prueba esto, me está funcionando,

Necesitamos configurar Pods en Configuraciones,

El Proyecto-> Información-> Configuraciones en el proyecto Xcode (su proyecto) debe establecerse en 'Pods' del proyecto principal para Debug, Release (y qué más tiene). Consulte "Encabezados no encontrados: rutas de búsqueda no incluidas"

Espero que esto sea de ayuda para alguien.

Estoy trabajando con la integración de GoogleMaps Objective-C POD en iOS con mi aplicación Swift, por lo que para mí el problema era que el objetivo de prueba no tenía una referencia al archivo de encabezado de puente ( SWIFT_OBJC_BRIDGING_HEADER ) en la configuración de compilación. Asegúrese de que tanto su aplicación como los objetivos de la aplicación de prueba apunten a eso para que las llamadas de API de terceros (API de mapas, etc.) puedan usarse en pruebas de unidades rápidas.

La siguiente sintaxis me da el mejor resultado (probado con 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

Sin esto, tengo advertencias mientras se ejecuta la prueba sobre símbolos duplicados.

Después de esto, las advertencias desaparecieron.

Tuve problemas al usar OpenCV bajo XCTest. Me estaba dando errores de enlazador de Undefined symbols for architecture arm64para clases como cv::Mat. Estoy instalando OpenCV a través de CocoaPods usando pod 'OpenCV', '~> 2.0'debajo del objetivo principal. No importa cuánto intente poner la dependencia de OpenCV bajo el objetivo de prueba o inherit! :search_pathsno use nada de eso funcionó. La solución fue crear un abstract_targetlike así:

# 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 

También son útiles los comandos pod deintegrate& pod cleanque ayudan a limpiar el proyecto y aseguran que comiences de nuevo al probar. Puedes instalar esos dos usando [sudo] gem install cocoapods-deintegrate cocoapods-clean.