ios - unitarias - ¿Cómo se debe configurar un proyecto Swift+Objective-C para pruebas de unidad?
pruebas unitarias android (7)
Me resulta muy difícil descubrir cómo configurar los objetivos de prueba en Xcode 6b4. ¿Puede alguien señalarme en la dirección correcta dado este escenario?
Tengo un proyecto mayormente Swift. Sin embargo, existen dependencias de terceros de Objective-C, que se colocan en el encabezado de puente de la aplicación. Quiero escribir pruebas para mi código Swift. Idealmente, en Swift. El problema que tengo es esto ...
Si creo un caso de prueba Swift, el compilador se queja de que no puede encontrar los encabezados de Objective-C en el encabezado de puente de la aplicación.
Si creo un caso de prueba de Objective-C, entonces no puedo importar las clases de Swift que quiero probar.
Lo único que puedo hacer es escribir casos de pruebas de Objective-C, que no toquen ningún Swift. No puedo escribir "código / pruebas puramente Swift" debido a las dependencias de Objective-C.
¿Alguien tiene algún consejo o tuvo éxito en esto? ¿O es este el estado actual de las cosas en Beta 4?
Desde Xcode 6 Beta 4 notas de la versión de problemas conocidos:
Pruebas
• Las pruebas unitarias escritas en Objective-C actualmente no pueden importar el encabezado de interfaces generadas por Swift ("$ (PRODUCT_MODULE_NAME) -Swift.h") para los objetivos de la aplicación y, por lo tanto, no pueden utilizarse para probar el código que requiere este encabezado. (16931027)
• Solución alternativa: las pruebas unitarias para el código Swift se deben escribir en Swift. Las pruebas unitarias escritas en Objective-C para objetivos de marco pueden acceder a las interfaces generadas por Swift mediante la importación del módulo de marco usando ''@import FrameworkName;''.
Por lo tanto, actualmente no puedes probar el código Swift en Objective-C.
También de las notas de publicación:
Una limitación del sistema de control de acceso es que las pruebas unitarias no pueden interactuar con las clases y métodos en una aplicación a menos que se marquen como públicas. Esto se debe a que el objetivo de la prueba de la unidad no es parte del módulo de la aplicación.
Chris Lattner ha declarado en esta publicación en los foros de desarrolladores que aún están evaluando la situación para ver cómo pueden conciliar las pruebas unitarias y los controles de acceso recientemente implementados.
Por lo tanto, esperaría muchos cambios en las pruebas unitarias tanto en Swift como en proyectos que usan tanto Swift como Objective-C.
Hice el trabajo actualizando "Nombre de encabezado de interfaz generado por Objective-c" a "YourApplication-Swift.h"
La configuración predeterminada para esto es generar TargetName-Swift.h, el compilador nunca genera YourApplicaitonTest-Swift.h
Hicimos que esto funcionara, vi todos los errores posibles en el camino: errores de nombre de módulo al obtener un VC del guión gráfico, errores MyType_MyType_ específicos de las entidades de coredata, etc. pero esto fue lo peor.
El truco es usar el archivo -Swift.h del objetivo de compilación en lugar del objetivo de las pruebas, porque en el objetivo de las pruebas a veces hay que incluir archivos objc pero no archivos rápidos y objc no los reconocerá si están vinculados entre sí, pero en el objetivo de compilación todo está allí.
Lo primero es asegurarse de que el -Swift.h del objetivo de las pruebas no tenga el mismo nombre que el objetivo de compilación.
Incluya en las pruebas .pch o en cada archivo individual el -Swift del destino de depuración.
Deje que el compilador sepa dónde está ese archivo (en derivadas) editando las Rutas de búsqueda del encabezado del usuario con: $ (OBJROOT) /MyProjectName.build/Debug-iphonesimulator/MyProjectTarget.build/DerivedSources Si no está seguro, simplemente vaya a Buscador y encuentre los nombres. Si hay espacios en los nombres, debe agregar / antes de espacio
Puede encontrar más información sobre las variables del proyecto aquí: ¿Cómo imprimo una lista de "Configuraciones de compilación" en el proyecto Xcode?
La búsqueda de rutas de usuario siempre debe estar establecida en SÍ
No incluya los archivos rápidos en el objetivo de las pruebas, pero use @testable
Espero que Apple haya solucionado esto en el próximo xcode.
Intente colocar las sentencias #import "xyz-Swift.h"
en sus archivos de encabezado precompilados. De esa manera, tendrá diferentes declaraciones de importación para todos sus encabezados de Obj-C, dependiendo del destino:
MyProject-Prefix.pch (aplicación de destino):
#import "MyProject-Swift.h"
MyProjectTests-Prefix.pch (objetivo de prueba):
#import "MyProjectTests-Swift.h"
Me encontré con esta pregunta cuando intentaba averiguar cómo acceder al código Swift de mi proyecto a partir de mis pruebas Swift. Tanto mi proyecto como mis pruebas se iniciaron originalmente en Objective-C, por lo que tienen toda la configuración de los encabezados puente.
Para acceder a las clases Swift de mi proyecto, tuve que agregar:
@testable import MyProjectName
A la parte superior de mi archivo de prueba Swift. Después de construirlo para las pruebas, Xcode reconoció mi rápido código.
Espero que eso ayude a alguien más.
No estoy seguro de si todavía está buscando esto, ya que XCode 6 ya no está en versión beta, pero puede agregar su archivo de encabezado puente de Objective-C a su objetivo de prueba de unidad en la configuración de destino. Esto solucionó el problema para mí.
Tuve este problema e intenté resolverlo en la configuración de compilación para el objetivo de prueba. Cambiando las rutas de búsqueda, importando el encabezado rápido, importando cosas en el encabezado puente. Sin embargo, resultó estar en mi podfile. Tuve que agregar un link_with
con el objetivo de prueba. Me gusta esto:
platform :ios, ''8.0''
link_with ''YourApp'', ''YourAppTests''
pod ''ThePopularPod'', ''1.2.3'', :inhibit_warnings => true