Pero primero, una breve excursión histórica: Apple WWDC (WorldWide Developers Conference), o simplemente dub-dub, es una conferencia que Apple ha estado celebrando en California desde finales de los años ochenta. Este año, la conferencia se celebró en línea por primera vez. Y si los boletos anteriores se sortearon en una lotería, y aquellos que no recibieron el correo electrónico deseado tuvieron que contentarse con el video del sitio https://developer.apple.com/videos/ , este año, por razones obvias, no había otras opciones: todos vieron el video ...
Entonces, ¿qué podrías ver de las pruebas allí?
Haré una reserva de inmediato que en WWDC 2020 no hubo una gran sesión general dedicada a las pruebas en el ecosistema de Apple, como en años anteriores (Testing in Xcode 2019 y What's new in testing 2018 ,2017 ) Las novedades de prueba en 2020 se unieron en seis mini sesiones. ¡Vamos!
XCTSkip para tus pruebas
Xcode 11.4 agregó una nueva API para controlar el lanzamiento de pruebas basadas en condiciones: XCTSkip.
A menudo, en las pruebas, especialmente en las pruebas de integración, existen condiciones o requisitos que no son fáciles de ofuscar. Por ejemplo, una aplicación tiene alguna funcionalidad específica para un iPad que no funciona en un iPhone. O algunas características para una versión específica del sistema operativo.
Y antes, cuando las pruebas llegaban a tales casos (verificando la funcionalidad solo para iPad en el iPhone), había una opción:
- Terminar el caso de prueba;
- Marque la prueba como aprobada y siga adelante;
- No pasa la prueba.
Ahora tenemos un error por el cual la prueba actual deja de ejecutarse y se marca como omitida.
Por lo tanto, ahora XCTest tiene tres estados para la prueba aprobada en lugar de dos:
más detalles aquí y aquí .
Manejo de interrupciones y alertas en pruebas de IU
El manejo de interrupciones y alertas estaba en XCTest antes, pero en la sesión el mecanismo de su operación se reveló con más detalle. Me pareció interesante la nueva funcionalidad agregada en Xcode 11.4, iOS / tvOS 13.4 y macOS 10.15.4, a saber, restablecer permisos (también conocidos como recursos protegidos).
La conclusión es esta: si antes, por ejemplo, en la prueba n. ° 1, le dio acceso a la aplicación a la cámara o a los contactos, luego, en la prueba n. ° 2, este acceso no es tan fácil de quitar. Para hacer esto, deberá reinstalar la aplicación.
Ahora, utilizando la API para restablecer la autorización de recursos protegidos, puede seleccionar el acceso previamente otorgado:
Class XCUIApplication {
open func resetAuthorizationStatus(for: XCUIProtectedResource)
}Al restablecer los permisos, la aplicación se comporta como si nunca antes le hubiera pedido al usuario que acceda a recursos protegidos.
Esto le permite ir hasta el final con la emisión y recopilación de permisos para contactos, calendario, foto, micrófono, cámara y geolocalización. En iOS, también puede restablecer el acceso a la red de Bluetooth y teclado y, a partir de Xcode 12 / iOS 14, a los datos de Salud. En Mac OS, puede restablecer el acceso a los directorios Escritorio y Descargas.
A continuación se muestra un ejemplo de cómo restablecer el acceso de la aplicación a las fotos:
// Example
func testAddingPhotosFirstTime() throws {
let app = XCUIApplication()
app.resetAuthorizationStatus(for: .photos)
app.launch()
// Test code...
}Es importante recordar que a menudo (pero no siempre) restablecer los permisos mata la aplicación.
Más detalles aquí , aquí y aquí .
Eliminar los retrasos de animación con XCTest
Los retrasos de animación, o enganches, son comportamientos en los que un cuadro aparece más tarde de lo esperado.
La conferencia describe cómo prevenir la aparición de retrasos en la animación de su aplicación midiendo y probando con Performance XCTests.
También proporciona las mejores prácticas e identifica qué retrasos son tolerables y cuáles vale la pena tener en cuenta:
Describe por qué los retrasos críticos merecen una investigación cuidadosa y soluciones. El tema de probar la animación en sí es bastante extenso y merece un artículo separado, por lo que nos limitaremos a la parte introductoria y un enlace a la fuente .
Triaje y diagnóstico de pruebas caídas
Muchas veces arreglar las pruebas fallidas es una molestia que requiere mucho tiempo y recursos.
Xcode 12 tendrá una nueva API que debería facilitar la reparación de las pruebas fallidas. La API debería ayudar a responder rápidamente las preguntas: qué, cómo, por qué y lo más importante: ¿dónde cayó?
Si antes, después de que cayera la prueba, tenía que buscar el sitio del accidente en el
navegador Issue o el navegador de informes, entonces con Xcode 12 el proceso de búsqueda se ha vuelto más fácil: ahora el sitio del accidente está resaltado en la prueba misma.
Aparece un error con resaltado gris si la línea se refiere a alguna otra línea en el futuro:
Y en rojo si el error ocurrió directamente en esta línea:
Una nueva característica conveniente: abrir el editor de código no en una ventana separada, sino directamente en el navegador de informes:
Además, se agregó un nuevo objeto XCTIssue en Xcode 12, que, además de encapsular los datos de error que XCTest previamente recopiló en sí mismo (mensaje, ruta, número de línea y el indicador "Esperado"), ahora agrega:
- Tipos distintos;
- Descripción detallada;
- Error asociado;
- Archivos adjuntos.
Más detalles aquí y aquí .
Escribe pruebas para que fallen
El objetivo de los probadores es escribir pruebas para verlas pasar verdes, lo que significa que el producto puede enviarse a los usuarios finales. Sin embargo, escribir pruebas para verlas fallar también es necesario, porque una prueba fallida es muy probablemente un error encontrado. Por lo tanto, necesitamos escribir pruebas teniendo en cuenta el hecho de que en caso de que fallen, tendremos suficiente información para investigar.
Entonces, lo que se sugiere:
usar mensajes legibles por humanos en afirmaciones:
asegúrese de utilizar el tipo de afirmaciones apropiadas para su situación:
Desenvuelva los opcionales para hacer que sus pruebas se bloqueen arrojando un error en lugar de fallar. Swift proporciona varias formas de hacer esto, pero las pruebas tienden a usar XCTUnwrap, que es una simplificación de la construcción de guardia.
Use waitForExistence () en lugar de sleep () para esperas asincrónicas.
Use XCTContext.runActivity () para aumentar la legibilidad del registro de ejecución de prueba:
y si desea agregar un registro adicional, puede agregar un archivo adjunto, adjuntar una captura de pantalla o una salida del depurador como aquí. Esta característica es especialmente útil si sus pruebas se ejecutan en CI / CD.
Más detalles aquí .
Obtenga resultados de prueba más rápido
Es una pena cuando el lunes por la mañana descubres que el largo trabajo lanzado el viernes por la noche no ha funcionado hasta el final, colgado en el medio o incluso al principio. Y tiene que comenzar su semana laboral con un informe: ¿por qué sucedió esto? ¿Cómo puedes evitar esta situación en el futuro?
Xcode 12 presenta herramientas anticongelantes. Esta es una nueva opción para la prueba del plan de tiempo de ejecución.
Cuando está habilitado, Xcode establece un límite de tiempo sobre cómo se ejecuta cada prueba.
Si se excede el límite, Xcode hace lo siguiente:
- Recopila un informe (spindump);
- Mata una prueba colgada;
- Reinicia el corredor de prueba para que el resto de la suite pueda ejecutarse.
El informe (spindump) muestra cuál de los hilos, qué función pasó la mayor parte del tiempo. Esto le permitirá ver el cuello de botella de sus pruebas con los ojos incluso antes de que su café / té de la mañana se haya enfriado.
De manera predeterminada, se asignan 10 minutos para cada prueba, y si la prueba se completa más rápido, el temporizador se restablece a cero para la próxima prueba. Si necesita más / menos tiempo para cada prueba en su conjunto de pruebas, puede cambiar el valor predeterminado en la configuración del plan de prueba.
También puede hacerlo utilizando la opción de comando xcodebuild:
xcodebuild option
-default-test-execution-time-allowance <seconds>Del mismo modo, puede establecer el tiempo máximo de ejecución de la prueba:
xcodebuild option
-maximun-test-execution-time-allowance <seconds>Incluso si necesita establecer el tiempo de ejecución para una prueba o clase de prueba específica, esto también es posible utilizando la API executeTimeAllowance:
Class XCTestCase: XCTest {
var executionTimeAllowance: TimeInterval //
}Ajustar la ejecución de una prueba en particular le ahorrará tiempo, pero esto no es todo lo que se puede hacer para acelerar el paso de una larga serie de pruebas.
Xcode 12 le permite ejecutar pruebas en múltiples dispositivos al mismo tiempo. Esta característica se llama Prueba distribuida paralela. Los beneficios de ejecutar pruebas en múltiples dispositivos son obvios: un ahorro de tiempo decente.
Pero, desafortunadamente, también existen dificultades: el orden de lanzamiento de las pruebas en paralelo no es determinista, no hay garantía de que la prueba número 6 se ejecute en el dispositivo # 1 después de la prueba número 5. Este hecho debe tenerse en cuenta al planificar el lanzamiento de pruebas usando Parallel Pruebas distribuidas.
En general, la idea de ejecutar pruebas en paralelo no es nueva. Hubo tal oportunidad antes de Xcode 12, pero fue en Xcode 12 que fue posible ejecutar pruebas en dispositivos reales (hasta ahora solo usando xcodebuild).
El comando para ejecutar pruebas distribuidas paralelas es el siguiente:
xcodebuild test
-project MyProject.xcodeproj
-scheme MyProject
-parallel-testing-enabled YES
-parallelize-test-among-desinations
-destination 'platform=iOS,name=iPhone 11'
-destination 'platform=iOS,name=iPad pro' Más detalles aquí .
Esto concluye la revisión de las nuevas características de prueba de WWDC 2020. Gracias por leer hasta el final.
Espero que encuentre útil este artículo. ¡Feliz prueba!