ios - sincronizar - no puedo ver mi musica en mi iphone 6

Bibliotecas no encontradas al usar CocoaPods con pruebas lógicas de iOS

Question

Intento escribir algunas pruebas lógicas de iOS contra clases en mi proyecto que usan funcionalidades de algunas de las bibliotecas en mi podspec. Estoy utilizando el paquete de prueba de unidad estándar proporcionado en Xcode (aunque no las pruebas de aplicación, solo las pruebas de unidad).

Por ejemplo, uso Magical Record, y tengo esa biblioteca vinculada en mi podspec. Está presente en el proyecto Pods en mi área de trabajo y funciona como se espera cuando la aplicación se ejecuta en el simulador o en el dispositivo. Cuando trato de vincular a la prueba el objeto que utiliza Magical Record, sin embargo, aparece un error del enlazador que indica que no puede encontrar los selectores de Magical Record. Intenté actualizar HEADER_SEARCH_PATH en mi paquete de prueba lógica, incluso codificándolo en el directorio de encabezados creado por CocoaPods, pero sin suerte.

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

¿Estoy haciendo esto mal? ¿Debo hacer algo más para que el compilador vea las bibliotecas de CocoaPods?

Answer 1

A partir de CocoaPods 1.x, existe una nueva forma de declarar dependencias compartidas entre un objetivo y el objetivo de prueba correspondiente. Hasta ahora había utilizado la solución aceptada por Mark Struzinski, pero el uso de este método arrojó un gran número de advertencias cuando ejecuté 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 que nuestro objetivo de prueba hereda a través de las rutas de búsqueda del objetivo principal, así:

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 -Test tenga acceso a las dependencias del objetivo de la aplicación, sin múltiples copias binarias. Esto ha acelerado seriamente los tiempos de construcción de pruebas para mí.

Answer 2

Agregué :exclusive => true para evitar errores de símbolos duplicados en el objetivo de la 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 la prueba de la aplicación a la prueba de la unidad lógica, se produce el error del enlazador. 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 => true establece que todo lo que se do...end afuera do...end NO se debe vincular a myProjectTests , lo cual es razonable en los objetivos de prueba de la aplicación, pero causará errores del enlazador en los objetivos de prueba lógica.

Answer 3

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 quiere usar es link_with desde su Podfile . Algo como:

link_with ''MainTarget'', ''MainTargetTests''

A continuación, ejecute pod install nuevo.

Answer 4

Estoy de acuerdo con las otras respuestas que dicen que es necesario vincular las bibliotecas con los objetivos de prueba. Sin embargo, ninguna de las sugerencias hasta ahora me ha ayudado. Como @fabb escribe en un comentario: "al probar, isSubclassOfClass: llamadas devuelven NO donde deben devolver SÍ. La única razón por la que puedo explicar esto es que las dependencias realmente se vinculan tanto con el objetivo principal como con el objetivo de prueba, y cuando la prueba el cargador de paquetes del objetivo 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 obtuve para trabajar fue actualizar mi Podfile para definir Pod 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

Fue necesario especificar un Pod para mi objetivo de prueba, aunque no usé ningún Pod específico para la 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.

Answer 5

Estoy trabajando con la integración de GoogleMaps Objective-C POD en iOS con mi aplicación Swift y 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 la aplicación como los objetivos de la aplicación de prueba apuntan a eso para que las llamadas de API de terceros (API de mapas, etc.) se puedan usar en pruebas rápidas de unidades.

Answer 6

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.

Answer 7

La siguiente sintaxis me da el mejor resultado (probado en 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 durante la prueba de símbolos duplicados.

Después de estas advertencias desaparecieron.

Answer 8

Mi solución a este problema fue cambiar mi archivo Pod 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 dado que estoy usando swift también tuve que configurar el objetivo de prueba para incluir el archivo MyApp-Bridging-Header.h . (En el grupo Swift Compiler en la pestaña Build Settings)

Answer 9

Pensé en esto viendo 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 del proyecto y hace clic en la pestaña Información, verá sus configuraciones de construcción en la sección superior. Si abre el triángulo de revelación para sus diferentes configuraciones, verá Pods listados 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} de mi destino principal y copiarlos en el destino de la prueba lógica en Build Settings / HEADER_SEARCH_PATHS.

Finalmente, tuve que agregar libPods.a en la fase de construcción del enlace binario con las bibliotecas para mi objetivo de pruebas lógicas.

Espero que esto sea capaz de ayudar a alguien más.

Answer 10

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

En caso de que tenga vainas comunes y específicos para cada objetivo, es posible que desee utilizar la opción "def" para definir un grupo de vainas. y use la "def" más tarde en el 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 los dos objetivos, y ''Typhoon'' solo al objetivo ''MyProject''

Answer 11

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

232 duplicate symbols for architecture i386

Para solucionarlo, simplemente elimine una de las referencias de libPods.a en su Project Explorer.

Answer 12

Tuve una incidencia similar cuando perdí algunos archivos de la biblioteca durante el control de algunas versiones. Todavía vi el archivo de la biblioteca en mis Pods, pero con el código real perdido, XCode dijo que se había ido. Para mi sorpresa, ejecutar ''pod install'' no devolvió inmediatamente los archivos perdidos.

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

1. Eliminar la biblioteca del archivo Podfile
2. Ejecute ''pod install'' para eliminar completamente la biblioteca
3. Vuelva a colocar la biblioteca en el archivo Podfile
4. Ejecuta ''pod install'' de nuevo

Esto debería volver a cuestionar la biblioteca en su forma original.