Probó con éxito que la solución de i40west funciona para iniciar manualmente el simulador, pero parece una tontería que en la actualidad, un simulador de iOS requiera diferentes versiones de Xcode Y diferentes tipos de dispositivos cuando se ejecutan pruebas simultáneas desde la línea de comandos (caso de uso ligeramente diferente pero relacionado con la pregunta original en la parte superior )
Consulte el artículo de Apple aquí que es más relevante para las compilaciones y pruebas de línea de comandos:
https://developer.apple.com/library/ios/technotes/tn2339/_index.html
Múltiples pruebas simultáneas nos han funcionado bien si pasamos --args - correctos a 'iOS simulator.app' antes de ejecutar el comando 'prueba xcodebuild' con el lanzamiento correcto del simulador de coincidencia de valores '-destination' con el valor de UUID de la salida de 'xcrun simctl list ', y establecer la variable de entorno DEVELOPER_DIR para seleccionar diferentes binarios de la versión XCode (es decir, la ruta base a Xcode 6.1 y 6.4)
La razón para necesitar pruebas unitarias simultáneas en la misma máquina física y el mismo dispositivo simulador de iOS, como iPad o iPhone, y la misma versión de Xcode es principalmente compatible con CI (integración continua) de cualquier proyecto iOS por el cual el mismo sistema de compilación puede ejecutar más de 1 compilación de múltiples Las aplicaciones (nuestra empresa tiene 30 aplicaciones más o menos) a la vez al registrarse en las ramas de características son escaneadas y construidas automáticamente por el agente de Bamboo sin necesidad de esperar a que se completen otras compilaciones en ejecución: Bamboo admite este tipo de compilación automática en auto- ramas de características descubiertas si están habilitadas.
En cuanto a lo que sucede al ejecutar múltiples pruebas simultáneas, ejecutamos múltiples comandos 'xcodebuild test' dos veces seguidas en diferentes ventanas de Terminal.app, el resultado es que solo aparece una ventana de simulador y las pruebas fallan en la prueba más simple.
Cuando complicamos los criterios de entrada para nuestro lanzamiento de prueba, diferentes versiones de Xcode para cada sim y lanzamiento de prueba, cuando usamos DEVELOPER_DIR según las páginas de manual (prueba xcodebuild) estamos especificando un dispositivo diferente que se abre en dos ventanas separadas, pero el resultado es que cualquier prueba en ejecución en la primera ventana se ve interrumpida por la segunda ventana del simulador de iOS.
Parece que hay un recurso compartido común bajo el capó que se está interponiendo en el camino, no estoy seguro de lo que se pretende o simplemente una nueva característica que requiere más de unos días de reflexión seria sobre cómo implementar mejor las pruebas concurrentes sin impactos adversos.
No queremos usar máquinas virtuales para evitar las restricciones de simulación, ya que nuestra experiencia y la de otros en general es que el rendimiento de compilación de iOS en máquinas virtuales con gran cantidad de archivos pequeños es más lento que el hardware físico. Las máquinas virtuales generalmente retrasarán mucho la compilación debido a problemas de E / S en la combinación del software VMware y el hardware y / o firmware de Apple. Lo sentimos, virtualmente en el gueto, pero para nosotros las máquinas virtuales no funcionan bien: el sitio de virtualmente en el gueto nos ha proporcionado instrucciones sobre cómo instalar ESXi 5.5 en Mac Mini para nuestra granja de compilación.
Hemos experimentado el problema de rendimiento de la compilación con ESXi 5.5 en Mac Mini que es más lento que el metal desnudo incluso con SSD por un factor de 2 o más (es decir, una compilación de metal desnudo de 10 minutos toma 20 en VM). Consulte el artículo de resumen a continuación sobre por qué.
https://corner.squareup.com/2015/07/ios-build-infrastructure.html
La restricción de 1 dispositivo sim a la vez para pruebas de unidad xcodebuild reduce severamente la productividad y agrega exponencialmente costos significativos a Apple y al ecosistema.
El costo para Apple de no admitir la concurrencia para justificar más compras de hardware debe pensarse cuidadosamente, sopesando los riesgos de perder la velocidad del desarrollador frente a otros competidores que tienen menos restricciones en términos de simuladores y EULA.
La ventaja de las pruebas simultáneas en el inicio de sesión del mismo usuario (cómo funcionan la mayoría de los sistemas ci) es la calidad de las aplicaciones de la tienda de aplicaciones de la marca Apple, que a su vez es en parte lo que hace que las personas compren los dispositivos iOS. La mala calidad del software hace que toda la marca sea un poco más lenta y el soporte de concurrencia en simuladores de iOS definitivamente parece ser la forma inteligente de apoyar el ecosistema. Un pequeño corolario del problema en cuestión son las mejoras recientes, como el servidor Xcode de Apple para CI, la funcionalidad de pruebas automatizadas de IU de Xcode en Xcode 7.
Alentar gastos generales innecesarios para que las personas compren cantidades masivas de hardware, instalación, configuración, sin mencionar a las numerosas personas necesarias para admitir todas las máquinas, redes y puntos de alimentación, etc., potencialmente dañará las ganancias de Apple al final, ya que no todos son como Apple y capaz de permitirse bastidores de MacPro o Mac Mini solo para soportar pruebas concurrentes en simuladores. El objetivo de un simulador es evitar el uso del hardware y también acelerar las pruebas.
Además, las limitaciones de EULA en las máquinas virtuales hacen que el caso de las máquinas virtuales en Mac Pro sea bastante débil. Este tipo de hardware sería atractivo si se pudieran ejecutar varios sims, pero dado que no se admiten pruebas unitarias simultáneas (excepto en las dos condiciones anteriores: una versión XCode diferente y un dispositivo simulador diferente), probablemente nos quedaremos con Mac Mini para construir infraestructura.
Estas limitaciones de SIM y EULA de Apple no solo hacen que el proceso de compilación sea más lento sino que también agregan complejidad y costo innecesarios. Puede que no sea tan preocupante para las aplicaciones pequeñas, pero a medida que las aplicaciones crecen en tamaño y complejidad, la compilación puede demorar más de una hora (escuché que las compilaciones de Facebook iOS pueden tomar tanto tiempo). Nadie quiere esperar una hora para saber si pasó una compilación.
Conocemos soluciones de pirateo como ejecutar VM de ESXI en Mac Minis que no funcionan bien con OS X y xcodebuild en proyectos grandes con compilaciones que demoran más de 10 minutos en un Mac Book Pro o Mac Mini moderno, o diferentes cuentas de inicio de sesión en una máquina de metal desnudo al entorno solo para poder ejecutar pruebas concurrentes en la misma versión de Xcode y el mismo dispositivo simulador.
ESXi no es oficialmente compatible, aunque funciona bastante bien. Una de las razones por las que VMware podría no ser compatible con el hardware de Mac Mini todavía es la falta de memoria ECC, aunque Mac Pro es compatible ya que tiene memoria ECC, es probable que tenga los mismos problemas que Mac Mini en términos de versiones de iOS más lentas en comparación con el metal desnudo prueba en la misma configuración de hardware y software (el único cambio es VM versus bare metal con OS X). MacPro no ha sido probado por nosotros en este momento. En nuestra experiencia, VMware Fusion también es bastante lento en términos de rendimiento.
Más importante aún, los desarrolladores deberán esperar más tiempo cuando los problemas mencionados se combinen a menos que el conjunto de máquinas sea lo suficientemente grande como para soportar una línea de cambios (una compilación de CI por cada 2 desarrolladores, relación muy alta de máquinas por desarrollador). Las máquinas de compilación de CI deberían poder ejecutar más compilaciones concurrentes y más pruebas concurrentes que 1.
Una de las otras observaciones sobre los simuladores de iOS es que parecen ser un trabajo en progreso y completamente inacabados incluso después de 7 versiones principales. El subcomando 'xcrun simctl' tiene una opción --set que puede permitir cierta flexibilidad de algún tipo pero no está seguro de qué valor posible es válido, y lo mismo con --noxpc. Nadie debería tener que adivinar los valores apropiados y, además, debería haber una página de manual que cubra esta opción y quizás un ejemplo. ¿Cuáles son algunos casos de uso para estas 2 opciones interesantes?
Puede decir, bueno, ninguna aplicación debe diseñarse para tener una gran superficie que garantice la ejecución de pruebas concurrentes, y hacer uso de una mejor arquitectura basada en XPC, ya que las aplicaciones monolíticas son el problema. Esto puede ser correcto, no es una solución tan pragmática como podríamos esperar, y el problema persiste si tiene más de 20 aplicaciones para construir en la misma infraestructura.
Hacer que la configuración y los procesos de la máquina sean tan genéricos y escalables como sea posible para un mayor rendimiento requerirá algo de trabajo en el simulador (aplicación + desarrolladores centrales). También requiere un alto nivel de colaboración entre todos los desarrolladores de simuladores de Apple y el propietario (s) del producto del simulador necesita ordenar la cartera de pedidos del producto correctamente para que este problema llame la atención :-)
