Testou com êxito que a solução da i40west funciona para iniciar manualmente o simulador, mas parece tolo que atualmente, um simulador iOS exija diferentes versões do Xcode E diferentes tipos de dispositivos ao executar testes simultâneos na linha de comando (caso de uso ligeiramente diferente, mas relacionado à pergunta original na parte superior) )
Consulte o artigo da Apple aqui que é mais relevante para compilações e testes de linha de comando:
https://developer.apple.com/library/ios/technotes/tn2339/_index.html
Vários testes simultâneos funcionaram bem para nós ao passar --args - corretos para 'iOS simulator.app' antes de executar o comando 'xcodebuild test' com o valor correto '-destination' correspondente ao lançamento do simulador com o valor de UUID da saída de 'xcrun lista simctl 'e definindo a variável de ambiente DEVELOPER_DIR para selecionar binários diferentes da versão do XCode (ou seja, caminho base para o Xcode 6.1 e 6.4)
O motivo para a necessidade de testes de unidade simultâneos na mesma máquina física e no mesmo dispositivo simulador iOS, como iPad ou iPhone e a mesma versão do Xcode, é principalmente para dar suporte ao IC (integração contínua) de qualquer projeto iOS, pelo qual o mesmo sistema de compilação pode executar mais de uma compilação de vários aplicativos (nossa empresa possui mais ou menos 30 aplicativos) por vez no check-in, os ramos de recursos são verificados e construídos automaticamente pelo agente Bamboo sem a necessidade de aguardar a conclusão de outras Builds em execução - o Bamboo suporta esse tipo de criação automática em ramificações de recurso descobertas, se ativadas.
Quanto ao que acontece ao executar vários testes simultâneos, executamos vários comandos 'xcodebuild test' duas vezes seguidas em diferentes janelas Terminal.app, o resultado é apenas uma janela do simulador e os testes falham no teste mais simples.
Quando complicamos os critérios de entrada para nosso lançamento de teste, versões diferentes do Xcode para cada sim e lançamento de teste, ao usar DEVELOPER_DIR de acordo com as páginas de manual (teste do xcodebuild), estamos especificando um dispositivo diferente que se abre em duas janelas separadas, mas o resultado é que todos os testes em execução na primeira janela são interrompidos pela segunda janela do simulador do iOS.
Parece haver um recurso compartilhado comum oculto que está atrapalhando, não tenho certeza de que ele se destina ou apenas um novo recurso que requer mais de alguns dias de reflexão séria sobre como implementar melhor as execuções simultâneas de testes sem impactos adversos.
Não queremos usar VMs para solucionar as restrições do sim, pois nossa experiência e outras em geral é que o iOS constrói desempenho em VMs com grande número de arquivos pequenos e é mais lento que o hardware físico. As VMs geralmente diminuem bastante a compilação devido a problemas de E / S na combinação do software VMware e hardware e / ou firmware da Apple. Desculpe, virtualmente, mas para nós, as VMs não têm um bom desempenho - o site do virtghetto nos forneceu instruções sobre como instalar o ESXi 5.5 nos Mac Mini para nosso farm de criação.
Ocorreu um problema no desempenho da compilação, com o ESXi 5.5 no Mac Mini sendo mais lento que o bare metal, mesmo com SSD por um fator de 2 ou mais (ou seja, uma compilação baremetal de 10 minutos leva 20 na VM). Consulte o artigo abaixo sobre o motivo.
https://corner.squareup.com/2015/07/ios-build-infrastructure.html
A restrição de um dispositivo SIM por vez para testes de unidade xcodebuild reduz drasticamente a produtividade e adiciona exponencialmente custos significativos à Apple e ao ecossistema.
O custo para a Apple de não oferecer suporte à concorrência para justificar mais compras de hardware deve ser pensado com cuidado, ponderando os riscos de perda da velocidade do desenvolvedor contra outros concorrentes que têm menos restrições em termos de sims e EULA.
A vantagem de testes simultâneos no mesmo login de usuário (como a maioria dos sistemas ci funciona) é a qualidade dos aplicativos da loja de aplicativos da marca Apple, que por sua vez é em parte o que leva as pessoas a comprar os dispositivos iOS em primeiro lugar. A má qualidade do software torna toda a marca um pouco mais lenta e o suporte simultâneo nos simuladores iOS definitivamente parece ser o caminho inteligente a seguir para apoiar o ecossistema. Um pouco do corolário do problema em questão são as melhorias recentes, como o servidor Xcode da Apple para CI, a funcionalidade automatizada de testes de interface do usuário do Xcode no Xcode 7.
Incentivar despesas desnecessárias para levar as pessoas a comprar grandes quantidades de hardware, instalação, configuração, sem mencionar várias pessoas necessárias para suportar todas as máquinas, pontos de rede e pontos de energia etc., potencialmente prejudicará os lucros da Apple no final, pois nem todos são como a Apple e capaz de comprar racks de MacPro ou Mac Mini apenas para suportar testes simultâneos em simuladores. O objetivo de um simulador é evitar o uso do hardware e também acelerar os testes.
Além disso, as limitações do EULA em VMs tornam o caso das VMs no Mac Pro bastante fraco. Esse tipo de hardware seria atraente se vários simuladores pudessem ser executados, mas como testes de unidade simultâneos não são suportados (exceto nas duas condições acima - versão XCode diferente e dispositivo simulador diferente), provavelmente ficaremos com os Mac Mini para criar infraestrutura.
Essas limitações de sim e EULA da Apple não apenas tornam o pipeline de construção mais lento, mas também adicionam complexidade e custo desnecessários. Pode não ser tão preocupante para aplicativos pequenos, mas como os aplicativos aumentam em tamanho e complexidade, a compilação pode levar mais de uma hora (ouvi dizer que as compilações do Facebook iOS podem levar tanto tempo). Ninguém quer esperar uma hora para saber se uma compilação foi aprovada.
Conhecemos soluções de hackers, como a execução de VMs ESXI no Mac Minis, que não apresentam bom desempenho com o OS X e o xcodebuild em grandes projetos com builds que levam mais de 10 minutos em um moderno Mac Book Pro ou Mac Mini ou em contas de login diferentes na máquina bare metal para o ambiente apenas para poder executar testes simultâneos na mesma versão do Xcode e no mesmo dispositivo simulador.
O ESXi não é oficialmente suportado, embora funcione muito bem. Uma das razões pelas quais a VMware pode não oferecer suporte ao hardware do Mac Mini ainda é a falta de memória ECC, embora o Mac Pro seja suportado por possuir memória ECC, provavelmente tem os mesmos problemas que os do Mac Mini em termos de compilações do iOS mais lentas em comparação com o bare metal testes na mesma configuração de hardware e software (apenas a alteração é VM versus bare metal executando o OS X). O MacPro ainda não foi testado por nós. Em nossa experiência, o VMware Fusion também é bastante lento em termos de desempenho.
Mais importante ainda, os desenvolvedores precisarão esperar mais quando os problemas mencionados forem combinados, a menos que o conjunto de máquinas seja grande o suficiente para suportar várias linhas de mudanças (uma compilação de IC para cada 2 desenvolvedores, proporção muito alta de máquinas para desenvolvedor). As máquinas de criação de IC devem poder executar mais compilações simultâneas e testes simultâneos que 1.
Uma das outras observações sobre os simuladores do iOS é que eles parecem ser um trabalho em andamento e completamente inacabado, mesmo após 7 versões principais. O subcomando 'xcrun simctl' possui uma opção --set que pode permitir algum tipo de flexibilidade, mas não tem certeza de qual valor possível é válido e o mesmo com --noxpc. Ninguém precisa adivinhar valores apropriados e, além disso, deve haver uma página de manual que cubra essa opção e, talvez, exemplo. Quais são alguns casos de uso dessas duas opções interessantes?
Você pode dizer que, bem, nenhum aplicativo deve ser projetado para ter uma área ocupada que justifique a execução simultânea de testes e o uso de uma arquitetura melhor baseada no XPC, pois os aplicativos monolíticos são o problema. Isso pode muito bem estar correto, não é uma solução pragmática como poderíamos esperar, e o problema permanece se você tiver mais de 20 aplicativos para construir na mesma infraestrutura.
Tornar a configuração e os processos da máquina o mais genérico e escalável possível para maior produtividade exigirá algum trabalho no simulador (app + desenvolvedores principais). Também requer um alto nível de colaboração entre todos os desenvolvedores de simuladores da Apple e o (s) proprietário (s) do produto, solicitando o backlog do produto corretamente para que esse problema receba atenção :-)
