Testé avec succès que la solution d'i40west fonctionne pour lancer manuellement le simulateur, mais semble ridicule qu'à cette époque, un simulateur iOS nécessite différentes versions de Xcode ET différents types d'appareils lors de l'exécution de tests simultanés à partir de la ligne de commande (cas d'utilisation légèrement différent mais lié à la question originale en haut ).
Reportez-vous à l'article Apple ici, qui est le plus pertinent pour les versions et les tests de ligne de commande:
https://developer.apple.com/library/ios/technotes/tn2339/_index.html
Plusieurs tests simultanés ont bien fonctionné pour nous si nous transmettons le bon --args - à 'iOS simulator.app' avant d'exécuter la commande 'xcodebuild test' avec la valeur correcte '-destination' correspondant au lancement simultané avec la valeur UUID de la sortie de 'xcrun simctl list ', et paramétrer la variable d'environnement DEVELOPER_DIR pour sélectionner différents binaires de version XCode (c'est-à-dire le chemin de base vers Xcode 6.1 et 6.4)
La raison pour laquelle des tests unitaires simultanés sur la même machine physique et le même appareil de simulation iOS tels que l'iPad ou l'iPhone et la même version de Xcode sont principalement de prendre en charge CI (intégration continue) de tout projet iOS dans lequel le même système de build peut exécuter plus d'une build de plusieurs Les applications (notre société a environ 30 applications) à la fois lors de l'enregistrement sur les branches de fonctionnalités sont automatiquement analysées et créées par l'agent Bamboo sans avoir besoin d'attendre la fin des autres builds en cours d'exécution - Bamboo prend en charge ce type de build automatique sur auto- branches de fonctionnalités découvertes si activées.
En ce qui concerne ce qui se passe lors de l'exécution de plusieurs tests simultanés, nous exécutons plusieurs commandes `` xcodebuild test '' deux fois de suite dans différentes fenêtres Terminal.app, le résultat est qu'une seule fenêtre de simulateur apparaît et les tests échouent dans le test le plus simple.
Lorsque nous compliquons les critères d'entrée pour notre lancement de test, différentes versions de Xcode pour chaque lancement de simulation et de test, lors de l'utilisation de DEVELOPER_DIR selon les pages de manuel (test xcodebuild), nous spécifions un périphérique différent qui s'ouvre dans deux fenêtres séparées, mais le résultat est que tous les tests en cours dans la première fenêtre sont interrompus par la deuxième fenêtre du simulateur iOS.
Il semble y avoir une ressource partagée commune sous le capot qui se met en travers, pas sûr que ce soit prévu ou juste une nouvelle fonctionnalité qui nécessite plus de quelques jours de réflexion sérieuse sur la façon de mieux implémenter des tests simultanés sans impacts négatifs.
Nous ne voulons pas utiliser de machines virtuelles pour contourner les restrictions de la simulation, car notre expérience et d'autres en général montrent que les performances de construction d'iOS sur des machines virtuelles avec un grand nombre de petits fichiers sont plus lentes que le matériel physique. Les VM ralentissent généralement considérablement la construction en raison de problèmes d'E / S liés à la combinaison du logiciel VMware et du matériel et / ou du micrologiciel Apple. Désolé virtuellement ghetto, mais pour nous, les machines virtuelles ne fonctionnent pas bien - le site virtuellement ghetto nous a fourni des instructions sur la façon d'installer ESXi 5.5 sur Mac Mini pour notre ferme de construction.
Nous avons constaté que le problème des performances de construction avec ESXi 5.5 sur Mac Mini était plus lent que le bare metal, même avec un SSD, d'un facteur 2 ou plus (c'est-à-dire qu'une construction de baremetal de 10 minutes prend 20 sur VM). Reportez-vous à l'article de squareup ci-dessous pour savoir pourquoi.
https://corner.squareup.com/2015/07/ios-build-infrastructure.html
La restriction d'un seul appareil sim à la fois pour les tests unitaires xcodebuild réduit considérablement la productivité et ajoute de façon exponentielle des coûts importants pour Apple et l'écosystème.
Le coût pour Apple de ne pas prendre en charge la concurrence pour justifier davantage d'achats de matériel doit être soigneusement étudié, en pesant les risques de perte de vitesse de développement par rapport à d'autres concurrents qui ont moins de restrictions en termes de sims et de CLUF.
L'avantage des tests simultanés dans la même connexion utilisateur (comment la plupart des systèmes ci fonctionnent) est la qualité des applications de l'App Store de marque Apple, qui à son tour est en partie ce qui incite les gens à acheter les appareils iOS en premier lieu. La mauvaise qualité du logiciel rend toute la marque un peu plus lente et la prise en charge de la concurrence dans les simulateurs iOS semble définitivement être la manière intelligente de prendre en charge l'écosystème. Les améliorations récentes telles que le serveur Xcode d'Apple pour CI, la fonctionnalité de tests d'interface utilisateur automatisés de Xcode dans Xcode 7, constituent un corollaire du problème en question.
Encourager les frais généraux inutiles pour inciter les gens à acheter des quantités massives de matériel, de configuration, de configuration, sans parler de nombreuses personnes nécessaires pour prendre en charge toutes les machines, le réseau et les points d'alimentation, etc., nuira potentiellement aux bénéfices d'Apple à la fin car tout le monde n'est pas comme Apple et capable de se payer des racks de MacPro ou Mac Mini juste pour prendre en charge des tests simultanés sur des simulateurs. L'intérêt d'un simulateur est d'éviter d'utiliser le matériel et d'accélérer les tests.
De plus, les limitations du CLUF sur les VM rendent les arguments en faveur des VM sur Mac Pro assez faibles. Ce type de matériel serait attrayant si plusieurs sims pouvaient fonctionner, mais comme les tests unitaires simultanés ne sont pas pris en charge (sauf dans les deux conditions ci-dessus - version XCode différente et appareil de simulation différent), nous allons probablement nous en tenir à Mac Mini pour l'infrastructure de construction.
Ces limitations de la carte SIM et du CLUF d'Apple rendent non seulement le pipeline de construction plus lent, mais ajoutent également une complexité et des coûts inutiles. Ce n'est peut-être pas si préoccupant pour les petites applications, mais à mesure que la taille et la complexité des applications augmentent, la construction peut prendre plus d'une heure (j'ai entendu dire que les versions de Facebook iOS peuvent prendre autant de temps). Personne ne veut attendre une heure pour savoir si une compilation a réussi.
Nous connaissons des solutions de piratage telles que l'exécution de VM ESXI sur Mac Minis qui ne fonctionnent pas bien en termes de performances avec OS X et xcodebuild sur de grands projets avec des builds qui prennent plus de 10 minutes sur un Mac Book Pro ou Mac Mini moderne, ou différents comptes de connexion sur une machine bare metal à l'environnement juste pour pouvoir exécuter des tests simultanés sur la même version Xcode et le même simulateur.
ESXi n'est pas officiellement pris en charge bien qu'il fonctionne plutôt bien. L'une des raisons pour lesquelles VMware peut ne pas encore prendre en charge le matériel Mac Mini est le manque de mémoire ECC, bien que Mac Pro soit pris en charge car il dispose d'une mémoire ECC, il a probablement les mêmes problèmes que le Mac Mini en termes de ralentissement des versions iOS par rapport au bare metal tests sur la même configuration matérielle et logicielle (seul le changement concerne la VM par rapport au bare metal sous OS X). MacPro n'a pas été testé par nous pour le moment. D'après notre expérience, VMware Fusion est également assez lent en termes de performances.
Plus important encore, les développeurs devront attendre plus longtemps lorsque les problèmes mentionnés ci-dessus sont aggravés, à moins que le pool de machines ne soit suffisamment grand pour prendre en charge la ligne des changements (un CI build pour 2 développeurs, rapport très élevé de machines par développeur). Les machines de build CI devraient pouvoir exécuter plus de builds simultanés et plus de tests simultanés que 1.
Une des autres observations sur les simulateurs iOS est qu'ils semblent être un travail en cours et complètement inachevé même après 7 versions majeures. La sous-commande 'xcrun simctl' a une option --set qui peut permettre une certaine flexibilité mais pas sûr de la valeur possible qui est valide, et de même avec --noxpc. Personne ne devrait avoir besoin de deviner les valeurs appropriées et de plus, il devrait y avoir une page de manuel qui couvre cette option et peut-être un exemple. Quels sont certains cas d'utilisation de ces 2 options intéressantes?
Vous pouvez dire qu'aucune application ne devrait être conçue pour avoir une grande empreinte qui justifie l'exécution de tests simultanés et utiliser une meilleure architecture basée sur XPC, car les applications monolithiques sont le problème. Cela peut très bien être correct, ce n'est pas une solution aussi pragmatique que nous pourrions l'espérer, et le problème persiste si vous avez plus de 20 applications à construire sur la même infrastructure.
Rendre une configuration de machine et des processus aussi génériques et évolutifs que possible pour un débit plus élevé nécessitera un certain travail sur le simulateur (application + développeurs principaux). Cela nécessite également un haut niveau de collaboration entre tous les développeurs de simulateurs Apple et le (s) propriétaire (s) du produit du simulateur doit commander correctement le backlog du produit pour que ce problème retienne l'attention :-)
