Me llamo Dmitri, soy tester en la empresa . Recientemente terminé de investigar una función relativamente nueva de — a saber, la prueba instrumental de aplicaciones iOS utilizando el marco de prueba nativo XCUITest.
Antes de esto, ya había probado Firebase Test Lab para Android y me gustó mucho, así que decidí intentar configurar la infraestructura de pruebas del proyecto iOS en el mismo camino. Tuve que buscar mucho en Google y no todo salió bien a la primera, por eso decidí escribir un tutorial para aquellos que aún tienen que enfrentarse a esto.
Así que, si tienes pruebas de UI en tu proyecto iOS, podrás intentar ejecutarlas hoy en dispositivos reales, amablemente proporcionados por la Corporación de la Bondad. Los interesados, bienvenidos al siguiente apartado.
En la narración decidí partir de algunos datos iniciales: un repositorio privado en GitHub y el sistema de construcción CircleCI. El nombre de la aplicación es AmazingApp, bundleID es com.company.amazingapp. Proporciono estos datos de antemano para reducir la confusión posterior.
Si has implementado ciertas soluciones en tu proyecto de manera diferente, comparte tu experiencia en los comentarios.
1. Las pruebas en sí
Creamos una nueva rama del proyecto para las pruebas de UI:
$ git checkout develop
$ git pull
$ git checkout -b “feature/add-ui-tests”
Abrimos el proyecto en XCode y creamos un nuevo Target con pruebas de UI [XCode -> File -> New -> Target -> iOS Testing Bundle], le damos un nombre descriptivo: AmazingAppUITests.
Pasamos a la sección de Build Phases del Target creado y comprobamos la existencia de Target Dependencies — AmazingApp, en Compile Sources — AmazingAppUITests.swift.
Es una buena práctica separar diferentes variantes de construcción en Schemas distintas. Creamos un esquema para nuestras pruebas de UI [XCode -> Product -> Scheme -> New Scheme] y le damos el mismo nombre: AmazingAppUITests.
El Build del esquema creado debe incluir el Target de la aplicación principal — AmazingApp y el Target de pruebas de UI — AmazingAppUITests — ver captura de pantalla.
A continuación, creamos una nueva configuración de construcción para las pruebas de UI. En XCode, hacemos clic en el archivo del proyecto, pasamos a la sección Info. Hacemos clic en “+” y creamos una nueva configuración, por ejemplo XCtest. Esto será necesario más adelante para evitar complicaciones cuando llegue el momento de la firma del código.
En tu proyecto hay al menos tres Targets: la aplicación principal, las pruebas unitarias (porque las tienes, ¿verdad?) y el Target de pruebas de UI que hemos creado.
Entramos en Target AmazingApp, en la pestaña Build Settings, sección Code Signing Identity. Para la configuración XCtest elegimos iOS Developer. En la sección Code Signing Style elegimos Manual. Aún no hemos generado el provisioning profile, pero más tarde regresaremos a él.
Para Target AmazingAppUITests hacemos lo mismo, pero en el campo Product Bundle Identifier escribimos com.company.amazingappuitests.
2. Configuración del proyecto en Apple Developer Program
Accedemos a la página de Apple Developer Program, pasamos a la sección Certificates, Identifiers & Profiles y luego al campo App IDs del apartado Identifiers. Creamos un nuevo App ID con el nombre AmazingAppUITests y bundleID com.company.amazingappuitests.
Ahora tenemos la posibilidad de firmar nuestras pruebas con un certificado separado, pero... El procedimiento de construcción de la build para pruebas implica la construcción de la propia aplicación y la construcción del runner de pruebas. Por lo tanto, enfrentamos el problema de firmar dos bundle ID con un solo provisioning profile. Afortunadamente, existe una solución simple y elegante: Wildcard App ID. Repetimos el procedimiento de creación de un nuevo App ID, pero en lugar de Explicit App ID elegimos Wildcard App ID como en la captura de pantalla.
En esta etapa, el trabajo con developer.apple.com ha terminado, pero no cerraremos la ventana del navegador. Vamos a y leemos sobre la utilidad Match de cabo a rabo.
El lector atento habrá notado que para usar esta utilidad necesitamos un repositorio privado y una cuenta que tenga acceso tanto al Apple Developer Program como a Github. Creamos (si es que no existe) una cuenta tipo InfrastructureAccount@your.company.domain, inventamos una contraseña fuerte, la registramos en developer.apple.com y asignamos como administrador del proyecto. Luego, damos acceso a la cuenta al repositorio de github de su empresa y creamos un nuevo repositorio privado con un nombre como AmazingAppMatch.
3. Configuración de Fastlane y la utilidad match
Abrimos la terminal, vamos a la carpeta del proyecto e inicializamos fastlane como se indica en Después de ingresar el comando
$ fastlane initse nos pedirá que elijamos las configuraciones disponibles. Elegimos la cuarta opción: configuración manual del proyecto.
En el proyecto aparece un nuevo directorio fastlane, que contiene dos archivos: Appfile y Fastfile. En pocas palabras, en Appfile almacenamos datos de servicio y en Fastfile definimos trabajos, que en la terminología de Fastlane se denominan lanes. Recomiendo leer la documentación oficial: , .
Abrimos Appfile en nuestro editor de texto favorito y lo ajustamos a la siguiente forma:
app_identifier "com.company.amazingapp" # ID del paquete
apple_dev_portal_id "infrastructureaccount@your.company.domain" # Cuenta de infraestructura creada, autorizada para editar el proyecto de iOS en el Programa de Desarrolladores de Apple.
team_id "LSDY3IFJAY9" # Su ID de equipo del portal de desarrollo
Regresamos a la terminal y comenzamos a configurar match según el manual oficial.
$ fastlane match init
$ fastlane match development
A continuación, introducimos los datos solicitados: repositorio, cuenta, contraseña, etc.
Importante: En el primer arranque, la herramienta match pedirá la contraseña para descifrar el repositorio. Es muy importante guardar esta contraseña, ¡la necesitaremos en la configuración del servidor CI!
En la carpeta fastlane se ha creado un nuevo archivo: Matchfile. Abrimos en nuestro editor de texto favorito y lo modificamos a:
git_url("https://github.com/YourCompany/AmazingAppMatch") # Repositorio privado creado para almacenar certificados y perfiles.
type("development") # El tipo predeterminado puede ser: appstore, adhoc, enterprise o development
app_identifier("com.company.amazingapp")
username("infrastructureaccount@your.company.domain") # Nombre de usuario de su cuenta de infraestructura en el portal de desarrolladores de Apple
Llenamos exactamente de esta manera si queremos usar match para firmar builds para su publicación en Crashlytics y/o AppStore, es decir, para firmar el ID del paquete de su aplicación.
Pero, como recordamos, creamos un ID comodín especial para firmar el build de prueba. Así que, abrimos Fastfile y escribimos la nueva lane:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests" # creamos una rama separada para el certificado de desarrollo para firmar el build de prueba.
)
end
Guardamos y escribimos en la terminal
fastlane testing_build_for_firebasey vemos cómo fastlane creó un nuevo certificado y lo colocó en el repositorio. ¡Excelente!
Abrimos XCode. Ahora tenemos el perfil de aprovisionamiento necesario: Match Development com.company.*, que debe indicarse en la sección de perfil de aprovisionamiento para los objetivos AmazingApp y AmazingAppUITests.
Solo queda añadir la lane para compilar las pruebas. Vamos a el proyecto del plugin para fastlane, que facilita la configuración de la exportación a Firebase Test Lab y seguimos las instrucciones.
Copiamos del ejemplo inicial para que nuestra lane testing_build_for_firebase se vea así al final:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests"
)
scan(
scheme: 'AmazingAppUITests', # Esquema de prueba de UI
clean: true, # Recomendado: Esto asegurará que la compilación no incluya archivos innecesarios
skip_detect_devices: true, # Requerido
build_for_testing: true, # Requerido
sdk: 'iphoneos', # Requerido
should_zip_build_products: true, # Debe ser verdadero para establecer el formato correcto para Firebase Test Lab
)
firebase_test_lab_ios_xctest(
gcp_project: 'AmazingAppUITests', # Nombre de tu proyecto en Google Cloud (regresaremos a esta línea más tarde)
devices: [ # Dispositivo(s) en el que ejecutar pruebas
{
ios_model_id: 'iphonex', # ID del modelo del dispositivo, ver comando de gcloud arriba
ios_version_id: '12.0', # ID de la versión de iOS, ver comando de gcloud arriba
locale: 'en_US', # Opcional: por defecto en_US si no se establece
orientation: 'portrait' # Opcional: por defecto en retrato si no se establece
}
]
)
end
Para obtener información completa sobre la configuración de fastlane en CircleCI, recomiendo leer la documentación oficial. .
No olvidemos agregar nuestra nueva tarea a config.yml:
build-for-firebase-test-lab:
macos:
xcode: "10.1.0"
working_directory: ~\/project
shell: \/bin\/bash --login -o pipefail
steps:
- checkout
- attach_workspace:
at: ~\/project
- run: sudo bundle install # actualizamos dependencias
- run:
name: install gcloud-sdk # en la máquina Mac es necesario instalar gcloud
command: |
ruby -e "$(curl -fsSL https:\/\/raw.githubusercontent.com\/Homebrew\/install\/master\/install)" \/dev\/null ; brew install caskroom\/cask\/brew-cask 2>\/dev\/null
brew cask install google-cloud-sdk
- run:
name: build app for testing
command: fastlane testing_build_for_firebase # ejecutamos la lane de compilación y envío a firebase
4. ¿Y qué pasa con nuestro entorno de prueba? Configurando Firebase.
Pasemos, en realidad, a lo que se escribió este artículo.
Es posible que tu aplicación esté usando Firebase en un plan gratuito, o tal vez no lo use en absoluto. No hay una diferencia fundamental, ya que para fines de prueba podemos crear un proyecto separado con un año de uso gratuito (genial, ¿no?)
Iniciamos sesión en nuestra cuenta de infraestructura (o en cualquier otra, no importa), y vamos a Creamos un nuevo proyecto llamado AmazingAppUITests.
Importante: En el paso anterior, en Fastfile en la lane firebase_test_lab_ios_xctest, el parámetro gcp_project debe corresponder al nombre del proyecto.
Las configuraciones predeterminadas nos satisfacen bastante.
No cerramos la pestaña, bajo la misma cuenta nos registramos en — esta es una medida necesaria, ya que la comunicación con Firebase se realiza a través de la interfaz de la consola de gcloud.
Google ofrece $300 al año, lo que en el contexto de las pruebas automatizadas equivale a un año de uso gratuito del servicio. Ingresamos los datos de pago, esperamos el cargo de prueba de $1 y recibimos $300 en la cuenta. Después de un año, el proyecto se transferirá automáticamente al plan gratuito, así que no hay que preocuparse por la posible pérdida de dinero.
Volvamos a la pestaña del proyecto Firebase y lo actualizamos al plan Blaze: ahora tenemos con qué pagar en caso de exceder el límite.
En la interfaz de gcloud, seleccionamos nuestro proyecto de Firebase, elegimos la opción del menú principal "Catálogo" y añadimos la API de Cloud Testing y la API de Cloud Tools Result.
Luego pasamos al menú "IAM y administración" -> Cuentas de servicio -> Crear cuenta de servicio. Otorgamos derechos de edición del proyecto.
Creamos una clave API en formato JSON.
El JSON descargado lo necesitaremos un poco más tarde, pero por ahora consideraremos que la configuración de Test Lab ha finalizado.
5. Configuración de CircleCI
Surge la pregunta razonable: ¿qué hacer con las contraseñas? Guardar de manera segura nuestras contraseñas y otros datos sensibles nos ayudará el mecanismo de variables de entorno de nuestra máquina de construcción. En la configuración del proyecto CircleCI seleccionamos Variables de Entorno.
Y añadimos las siguientes variables:
- key: GOOGLE_APPLICATION_CREDENTIALS
value: contenido del archivo json de clave de la cuenta de servicio gcloud - key: MATCH_PASSWORD
value: contraseña para descifrar el repositorio de github con los certificados - key: FASTLANE_PASSWORD
value: contraseña de la cuenta de infraestructura del Apple Developer Portal
Guardamos los cambios, creamos PR y lo enviamos a revisión a nuestro líder de equipo.
Resultados
Como resultado de estas simples maniobras, obtuvimos un buen entorno de trabajo estable con la posibilidad de grabar video de la pantalla del dispositivo durante la prueba. En el ejemplo de prueba, especifiqué el modelo de dispositivo iPhone X, pero la granja ofrece una rica variedad de combinaciones de diferentes modelos y versiones de iOS.
La segunda parte estará dedicada a la configuración paso a paso de Firebase Test Lab para el proyecto de Android.
Fuente: habr.com
