i40west의 솔루션이 시뮬레이터를 수동으로 실행하는 것으로 성공적으로 테스트했지만 오늘날 iOS 시뮬레이터는 명령 줄에서 동시 테스트를 실행할 때 다른 Xcode 버전과 다른 장치 유형을 필요로한다는 것이 어리석은 것처럼 보입니다 (약간 다른 사용 사례이지만 맨 위의 원래 질문과 관련됨). ).

명령 줄 빌드 및 테스트와 가장 관련이있는 Apple 문서를 참조하십시오.
https://developer.apple.com/library/ios/technotes/tn2339/_index.html

‘xcrun의 출력에서 ​​UUID 값과 일치하는 시뮬레이션 기 시작과 일치하는 올바른’-destination ‘값을 사용하여’xcodebuild test ‘명령을 실행하기 전에 올바른 –args-를’iOS simulator.app ‘에 전달하면 여러 동시 테스트가 제대로 작동했습니다. simctl list ‘및 DEVELOPER_DIR 환경 변수를 설정하여 다른 XCode 버전 바이너리 (예 : Xcode 6.1 및 6.4에 대한 기본 경로)를 선택합니다.

동일한 물리적 시스템과 iPad 또는 iPhone과 같은 동일한 iOS 시뮬레이터 장치 및 동일한 Xcode 버전에서 동시 단위 테스트가 필요한 이유는 주로 동일한 빌드 시스템이 여러 빌드의 둘 이상의 빌드를 실행할 수있는 모든 iOS 프로젝트의 CI (지속적 통합)를 지원하기위한 것입니다. 앱 (우리 회사에는 30 개 정도의 앱이 있음)이 기능 브랜치에서 체크인시 자동으로 스캔되고 다른 실행 빌드가 완료 될 때까지 기다릴 필요없이 Bamboo 에이전트가 빌드합니다 .Bamboo는 자동 빌드에서 이러한 유형의 자동 빌드를 지원합니다. 활성화 된 경우 기능 분기를 발견했습니다.

여러 개의 동시 테스트를 실행할 때 어떤 일이 발생하는지에 관해서는 다른 Terminal.app 창에서 여러 ‘xcodebuild test’명령을 연속으로 두 번 실행하면 결과는 하나의 시뮬레이터 창이 나타나고 가장 간단한 테스트에서 테스트가 실패합니다.

테스트 시작에 대한 입력 기준, 각 시뮬레이션 및 테스트 시작에 대한 다른 Xcode 버전을 복잡하게 만들 때 매뉴얼 페이지 (xcodebuild 테스트)에 따라 DEVELOPER_DIR을 사용할 때 두 개의 별도 창에서 열리는 다른 장치를 지정하지만 결과는 첫 번째 창에서 실행중인 모든 테스트는 두 번째 iOS 시뮬레이터 창에 의해 중단됩니다.

방해가되는 공통 공유 리소스가있는 것 같습니다. 의도 된 것인지 확실하지 않거나 부정적인 영향없이 동시 테스트 실행을 더 잘 구현하는 방법에 대해 며칠 이상 진지하게 생각해야하는 새로운 기능 일뿐입니다.

우리의 경험과 일반적으로 다른 사람들의 경험은 작은 파일이 많은 VM에서 iOS 빌드 성능이 물리적 하드웨어보다 느리기 때문에 VM을 사용하여 sim 제한 사항을 해결하고 싶지 않습니다. VM은 일반적으로 VMware 소프트웨어와 Apple 하드웨어 및 / 또는 펌웨어 조합의 I / O 문제로 인해 빌드 속도가 크게 느려집니다. 가상 게토로 미안하지만 우리에게는 VM이 ​​제대로 작동하지 않습니다. 가상 게토 사이트는 빌드 팜을 위해 Mac Mini에 ESXi 5.5를 설치하는 방법에 대한 지침을 제공했습니다.

Mac Mini에서 ESXi 5.5의 빌드 성능 문제가 SSD를 사용하더라도 베어 메탈보다 2 배 이상 느립니다 (즉, 10 분 베어 메탈 빌드는 VM에서 20 시간 소요). 이유에 대해서는 아래의 squareup 문서를 참조하십시오.

https://corner.squareup.com/2015/07/ios-build-infrastructure.html

xcodebuild 단위 테스트를 위해 한 번에 1 개의 sim 장치를 제한하면 생산성이 크게 저하되고 Apple과 생태계에 상당한 비용이 추가됩니다.

더 많은 하드웨어 구매를 정당화하기 위해 동시성을 지원하지 않는 Apple의 비용은 심 및 EULA 측면에서 제한이 적은 다른 경쟁 업체에 비해 개발자 속도를 잃을 위험을 고려하여 신중하게 고려해야합니다.

동일한 사용자 로그인 (대부분의 CI 시스템이 작동하는 방식)에서 동시 테스트의 장점은 Apple 브랜드 앱 스토어 앱의 품질이며, 이는 부분적으로 사람들이 처음에 iOS 기기를 구매하게 만듭니다. 열악한 소프트웨어 품질은 전체 브랜드를 조금 더 민첩하게 만들고 iOS 시뮬레이터의 동시성 지원은 확실히 생태계를 지원하는 현명한 방법처럼 보입니다. 당면한 문제의 결과는 CI 용 Apple의 Xcode 서버, Xcode 7의 Xcode의 자동화 된 UI 테스트 기능과 같은 최근 개선 사항입니다.

모든 기계, 네트워크 및 파워 포인트 등을 지원하는 데 필요한 수많은 사람은 말할 것도없고, 사람들이 대량의 하드웨어, 설정, 구성을 구매하도록 불필요한 오버 헤드를 장려하는 것은 결국 모든 사람이 Apple과 같지 않기 때문에 결국 Apple의 이익에 해를 끼칠 수 있습니다. 시뮬레이터에 대한 동시 테스트를 지원하기 위해 MacPro 또는 Mac Mini 랙을 구입할 수 있습니다. 시뮬레이터의 요점은 하드웨어 사용을 피하고 테스트 속도를 높이는 것입니다.

또한 VM에 대한 EULA 제한으로 인해 Mac Pro의 VM에 대한 사례는 매우 약합니다. 이 하드웨어 유형은 여러 시뮬레이션을 실행할 수 있다면 매력적일 수 있지만 동시 단위 테스트가 지원되지 않기 때문에 (위의 두 가지 조건-다른 XCode 버전과 다른 시뮬레이터 장치 제외) 빌드 인프라를 위해 Mac Mini를 고수 할 것입니다.

Apple의 이러한 시뮬레이션 및 EULA 제한으로 인해 빌드 파이프 라인이 느려질뿐만 아니라 불필요한 복잡성과 비용이 추가됩니다. 작은 앱에는 그다지 문제가되지 않지만 앱의 크기와 복잡성이 커짐에 따라 빌드에 1 시간 이상이 걸릴 수 있습니다 (페이스 북 iOS 빌드가 그렇게 오래 걸릴 수 있다고 들었습니다). 빌드가 통과되었는지 알기 위해 한 시간을 기다리는 사람은 없습니다.

우리는 Mac Mini에서 ESXI VM을 실행하는 것과 같은 해킹 솔루션을 알고 있는데, OS X에서는 성능이 좋지 않으며, 최신 Mac Book Pro 또는 Mac Mini에서 10 분 이상 걸리는 빌드 또는 다른 로그인 계정을 사용하는 대규모 프로젝트에서는 xcodebuild가 있습니다. 동일한 Xcode 버전 및 동일한 시뮬레이터 장치에서 동시 테스트를 실행할 수 있도록 베어 메탈 머신에서 환경에 연결합니다.

ESXi는 잘 작동하지만 공식적으로 지원되지 않습니다. VMware가 Mac Mini 하드웨어를 지원하지 않는 이유 중 하나는 ECC 메모리가 부족하기 때문입니다. Mac Pro는 ECC 메모리가 있기 때문에 지원되지만 iOS 빌드가 베어 메탈에 비해 느려진다는 점에서 Mac Mini와 동일한 문제가있을 수 있습니다. 동일한 하드웨어 및 소프트웨어 구성에서 테스트합니다 (OS X를 실행하는 베어 메탈에 비해 VM 만 변경됨). 현재 MacPro는 테스트를 거치지 않았습니다. 우리 경험상 VMware Fusion은 성능 측면에서도 상당히 느립니다.

더 중요한 것은 개발자가 앞서 언급 한 문제가 합쳐질 때 더 오래 기다려야 할 것입니다. 머신 풀이 변경 사항을 지원할만큼 충분히 크지 않은 경우 (개발자 2 명당 CI 빌드 1 개, 머신 대 개발자 비율이 매우 높음) CI 빌드 머신은 1보다 많은 동시 빌드와 더 많은 동시 테스트를 실행할 수 있어야합니다.

iOS 시뮬레이터에 대한 다른 관찰 중 하나는 7 개의 주요 버전 이후에도 진행중인 작업이고 완전히 미완성 된 것처럼 보인다는 것입니다. ‘xcrun simctl’하위 명령에는 어떤 종류의 유연성을 허용하지만 가능한 값이 유효한지 확실하지 않고 –noxpc와 동일한 –set 옵션이 있습니다. 누구도 적절한 값을 추측 할 필요가 없으며 더 나아가이 옵션과 예제를 다루는 man 페이지가 있어야합니다. 이 두 가지 흥미로운 옵션에 대한 사용 사례는 무엇입니까?

모 놀리 식 앱이 문제이므로 동시 테스트를 실행하고 XPC를 기반으로 한 더 나은 아키텍처를 사용해야하는 큰 공간을 갖도록 앱을 설계해서는 안된다고 말할 수 있습니다. 이것은 매우 정확할 수 있으며, 우리가 기대할 수있는 실용적인 솔루션이 아니며 동일한 인프라에 구축 할 20 개 이상의 앱이있는 경우 문제가 남아 있습니다.

더 높은 처리량을 위해 가능한 한 일반적이고 확장 가능한 머신 구성 및 프로세스를 만들려면 시뮬레이터 (앱 + 코어 개발자)에서 약간의 작업이 필요합니다. 또한 모든 Apple 시뮬레이터 개발자와 시뮬레이터 제품 소유자 간의 높은 수준의 협력이 필요하며이 문제에 대한주의를 끌려면 제품 백 로그를 올바르게 주문해야합니다. 🙂

답변

#!/bin/sh
PS3='Type the number of your choice (1, 2 or 3) and press Enter: '
options=("List Devices" "Run Simulator" "Quit")
select opt in "${options[@]}"
do
    case $opt in
        "List Devices")
            xcrun simctl list devices
            echo "\033[1m\n\nCopy the UDID in parentheses of the device which you want run and launch option 2 (Run Simulator)\033[0m"
            ;;
        "Run Simulator")
            read -p 'Type device UDID which you want launch: ' currentDeviceUDID
            open -n /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app/ --args -CurrentDeviceUDID $currentDeviceUDID
            ;;
        "Quit")
            break
            ;;
        *) echo invalid option;;
    esac
done