i40westのソリューションが手動でシミュレーターを起動するように機能することを正常にテストしましたが、現在の時代では、iOSシミュレーターはコマンドラインから同時テストを実行するときに異なるXcodeバージョンと異なるデバイスタイプを必要とする（使用例は少し異なりますが、最初の質問に関連しています） ）。
コマンドラインのビルドとテストに最も関連するAppleの記事を参照してください：https :
//developer.apple.com/library/ios/technotes/tn2339/_index.html
正しい--args-を 'iOS Simulator.app'に渡してから 'xcodebuild test'コマンドを実行し、正しい '-destination'値と一致するシミュレーターの起動を 'xcrunの出力からのUUIDの値で実行すると、複数の同時テストで問題なく機能しましたsimctl list '、およびDEVELOPER_DIR環境変数を設定して、異なるXCodeバージョンのバイナリ（つまり、Xcode 6.1および6.4へのベースパス）を選択する
同じ物理マシン、同じiPadやiPhoneなどのiOSシミュレーターデバイス、同じXcodeバージョンでユニットテストを同時に実行する必要がある理由は、同じビルドシステムで複数のビルドを複数実行できるように、iOSプロジェクトのCI（継続的インテグレーション）をサポートするためですアプリ（私たちの会社は30個程度のアプリを持っています）は、機能ブランチのチェックイン時に一度に自動的にスキャンされ、他の実行中のビルドが完了するのを待つ必要なくBambooエージェントによってビルドされます-Bambooはこのタイプの自動ビルドを自動でサポートします-有効になっている場合、機能ブランチを検出しました。
複数の同時テストを実行するとどうなるかについては、異なるTerminal.appウィンドウで複数の「xcodebuild test」コマンドを続けて2回実行すると、結果は1つのシミュレーターウィンドウだけになり、テストは最も単純なテストで失敗します。
テスト起動のエントリ基準を複雑にする場合、シムとテスト起動ごとに異なるXcodeバージョンを使用し、manページ（xcodebuildテスト）に従ってDEVELOPER_DIRを使用する場合、2つの異なるウィンドウで開く別のデバイスを指定しますが、結果は次のようになります。最初のウィンドウで実行中のテストはすべて、2番目のiOSシミュレーターウィンドウによって中断されます。
フードの下に共通の共有リソースがあるように見えますが、意図したものではないか、悪影響が出ないように並行テスト実行をより適切に実装する方法について数日以上真剣に検討する必要のある新機能です。
私たちの経験や他の人たちの一般的な経験では、多数の小さなファイルを含むVMでのiOSビルドのパフォーマンスは物理ハードウェアよりも遅いため、VMを使用してシミュレーションの制限を回避したくありません。VMは通常、VMwareソフトウェアとAppleハードウェアおよび/またはファームウェアの組み合わせにおけるI / Oの問題により、ビルドを大幅に遅くします。virtuallyghettoは申し訳ありませんが、私たちにとってVMはうまく機能しません-virtuallyghettoサイトでは、ビルドファーム用にMac MiniにESXi 5.5をインストールする方法についての説明を提供しています。
Mac MiniでのESXi 5.5のビルドパフォーマンスの問題は、SSDでもベアメタルよりも2倍以上遅いことを経験しました（つまり、10分のベアメタルビルドはVMで20かかります）。理由については、以下の記事を参照してください。
https://corner.squareup.com/2015/07/ios-build-infrastructure.html
xcodebuildユニットテストで一度に1つのsimデバイスを制限すると、生産性が大幅に低下し、アップルとエコシステムに大幅なコストが追加されます。
ハードウェアの購入を正当化するために同時実行性をサポートしないというAppleのコストは慎重に検討する必要があり、シムとEULAに関して制限の少ない他の競合他社と開発者の速度を失うリスクを比較検討する必要があります。
同じユーザーログインでの同時テストの利点（ほとんどのCIシステムが機能する方法）は、Appleブランドのアプリストアアプリの品質が、そもそもiOSデバイスを購入するきっかけにもなっていることです。ソフトウェア品質が低いため、ブランド全体が少し鈍くなり、iOSシミュレーターでの同時実行サポートがエコシステムをサポートするための賢明な方法のように思われます。当面の問題の帰結として、CI用のAppleのXcodeサーバー、Xcode 7のXcodeの自動UIテスト機能などの最近の改善があります。
すべてのマシン、ネットワーク、電源ポイントなどをサポートするために必要な多数の人々は言うまでもなく、人々に大量のハードウェア、セットアップ、構成を購入させるために不必要なオーバーヘッドを奨励すると、誰もがAppleやシミュレータでの同時テストをサポートするために、MacProまたはMac Miniのラックを購入することができます。シミュレータの重要なポイントは、ハードウェアの使用を避け、テストの速度を上げることです。
さらに、VMに関するEULAの制限により、Mac ProのVMは非常に脆弱です。このハードウェアタイプは、複数のシミュレーションを実行できる場合に魅力的ですが、同時ユニットテストがサポートされていないため（上記の2つの条件-異なるXCodeバージョンと異なるシミュレーターデバイスを除く）、ビルドインフラストラクチャにはMac Miniを使用します。
AppleによるこれらのシミュレーションとEULAの制限により、ビルドパイプラインが遅くなるだけでなく、不必要な複雑さとコストが追加されます。小さなアプリの場合はそれほど心配する必要はありませんが、アプリのサイズと複雑さが大きくなると、ビルドに1時間以上かかることがあります（Facebook iOSのビルドにはそれだけ時間がかかると聞きました）。ビルドが成功したかどうかを知るために1時間待つ必要はありません。
Mac MiniでのESXI VMの実行など、最新のMac Book ProやMac Mini、または別のログインアカウントでのビルドに10分以上かかるビルドを持つ大規模なプロジェクトでは、xcodebuildのパフォーマンスが上手く機能しないハックソリューションを知っています。同じXcodeバージョンと同じシミュレーターデバイスで同時テストを実行できるようにするために、ベアメタルマシンで環境に接続します。
ESXiは十分に機能しますが、正式にはサポートされていません。VMwareがMac Miniハードウェアをまだサポートしていない理由の1つはECCメモリがないことですが、Mac ProはECCメモリを備えているためサポートされていますが、iOSビルドに関してMac Miniと同じ問題がベアメタルと比較して遅くなります。同じハードウェアおよびソフトウェア構成でのテスト（変更点はVMとOS Xを実行するベアメタルのみです）。MacProは現時点ではテストされていません。私たちの経験では、VMware Fusionのパフォーマンスも非常に遅いです。
さらに重要なのは、マシンのプールが変更のパイプラインをサポートするのに十分な大きさでない限り、開発者は前述の問題が複合するとき、より長く待つ必要があります（2つの開発ごとに1つのCIビルド、開発者に対するマシンの比率が非常に高い）。CIビルドマシンは、1よりも多くの同時ビルドと同時テストを実行できる必要があります。
iOSシミュレータに関する他の観察結果の1つは、それらが進行中の作業であり、7つのメジャーバージョンの後でも完全に完成していないように見えることです。'xcrun simctl'サブコマンドには--setオプションがあります。これにより、ある種の柔軟性が得られる可能性がありますが、有効な値がどれであるかは不明で、-noxpcと同じです。だれも適切な値を推測する必要はありません。さらに、このオプションとおそらく例をカバーするmanページがあるはずです。これら2つの興味深いオプションの使用例は何ですか？
モノリシックアプリが問題であるため、同時実行テストの実行を保証し、XPCに基づくより優れたアーキテクチャを利用できるように設計されたアプリはありません。これは非常に正しい可能性があり、私たちが期待するほど実用的なソリューションではありません。同じインフラストラクチャ上に20以上のアプリを構築する必要がある場合は、問題が残ります。
マシンの構成とプロセスを可能な限り汎用的かつスケーラブルにしてスループットを高めるには、シミュレーター（アプリ+コア開発者）での作業が必要になります。また、すべてのAppleシミュレータ開発者とシミュレータ製品の所有者との間の高度なコラボレーションが必要であり、この問題について注意を引くために、製品のバックログを正しく注文する必要があります:-)
