Configuración de pruebas unitarias en proyectos mixtos Swift + Objective-C

Este artículo será pequeño, le diré qué problemas surgieron al crear un objetivo para probar en un proyecto ObjectiveC + Swift mixto y bastante antiguo, y cómo logré resolverlos.

Lo primero es confuso: un error en un objetivo de prueba puede afectar el lanzamiento de una prueba automática desde otro objetivo de prueba. Puede agregar cualquier número de objetivos para probar en el proyecto, generalmente se basan en el objetivo principal del proyecto y se agregan automáticamente a su esquema de inicio. Por lo tanto, al ejecutar cualquier prueba automática en este esquema, el resto se compilará y un error en uno de los objetivos de prueba interferirá con el lanzamiento de los otros. Para aislar este efecto, puede crear diferentes esquemas para diferentes objetivos de prueba.

Adjuntaré una captura de pantalla muy trivial, únicamente para mayor claridad:





El siguiente problema son las dependencias entre Objecive-C y Swift.
En su proyecto se crea:

MyProject-Bridging-Header.h : este archivo contiene los nombres de los archivos de encabezado ObjectiveC utilizados en swift.
MyProject-swift.h : crea implícitamente el código para las clases rápidas utilizadas en las clases ObjectiveC.
MyProject-Prefix.pch : el archivo de precompilación también puede contener dependencias de varias maneras, incluidas construcciones del tipo:

#ifdef __OBJC__ #import "MyProject-Swift.h" #endif 

Sus pruebas automáticas también pueden crear tales dependencias. Al agregar el primer archivo swift, Xcode ofrece crear un archivo de encabezado de puente para este objetivo de prueba. Todo funciona como un encanto. En teoría, el contenido de la prueba automática de cabecera de puente debería complementar el puente principal, pero de hecho, se produce un reemplazo. Por lo tanto, para tener acceso a todas las clases de proyecto en la prueba automática, especifico el encabezado de puente del objetivo principal en esta opción (imagen de arriba).

Vaya a Destino Xcode -> BuildSetting y verifique los siguientes parámetros:
Encabezado de puente Objective-C
Nombre de encabezado de interfaz generado por Objective-C
Especifique los principales archivos de destino.

Sin embargo, si tira del encabezado del puente principal, todas las dependencias comienzan a arrastrarse. Por lo tanto, también debe completar los siguientes parámetros con datos del proyecto principal:
Rutas de búsqueda del marco
Encabezados de búsqueda
Ruta de búsqueda de la biblioteca
Otras banderas de enlace
Runpath Search Paths NO necesita ser cambiado.

Luego se descubrió otro problema extraño:
Por alguna razón, en proyectos más antiguos, al objetivo de la prueba se le asigna el mismo nombre de módulo de producto que el principal. Esto no detuvo el solitario ObjectiveC, pero al agregar rapidez al proyecto, surgen dos problemas.

El primer problema es que en este caso

 @testable import MyProject 

el archivo de prueba automática se ignora y no puede acceder a las clases Swift.

El segundo problema es que dicho objetivo en la compilación sobrescribe MyProject-swift del objetivo principal y evita que se compilen otros objetivos. Este parámetro debe ser renombrado.

En esto, mi autotest comenzó y pude usar los archivos del proyecto, ¡lo que también deseo para ti!
No suelo trabajar en la configuración de un proyecto, por lo que todos los comentarios prácticos y consejos sobre este tema son bienvenidos.

Gracias a todos los que lo leyeron.

Source: https://habr.com/ru/post/460961/


All Articles