XCUITest를 활용해 안정적으로 돌아가는 테스트를 작성하기는 참 어렵습니다. 그러다보니 “XCUITest는 제대로 된 테스트 툴이 아니군! 다시는 쳐다보지도 말아야지”라는 생각을 하게 되는 분들도 많은 것 같습니다.
하지만 XCUITest을 기본적으로 “내 대신 눌러야 할 버튼들을 대신 눌러주는 로봇”으로 보게 된다면, 꼭 테스트를 위한 용도가 아니더라도 일상적인 업무 플로우를 훨씬 빠르게 만들어주는 훌륭한 툴이 될 수도 있습니다.
즉, 꼭 CI에서 돌아가는 테스트를 작성하기 위해서가 아니더라도,
•
내가 개발중인 화면으로 빠르게 이동하는
•
내가 개발한 내용이 잘 적용되었는지를 확인하는
정도의 용도로만 XCUITest를 활용해도, 훨씬 더 개발사이클을 빠르게 만들 수 있습니다. 이런 용도로만 사용하는 UITest들을 DeveloperTest라고 부르기도 합니다. (참조: DeveloperTest를 소개하는 영상)
DeveloperTest 추가하기
다만 테스트가 작성되는 파일들이 .gitignore된다는 점 만 다릅니다.
// .gitignore
DeveloperTests.swift
Plain Text
복사
개발중인 화면으로 이동하기
앱 개발의 일상적인 사이클은 다음과 같습니다.
1.
코드를 수정합니다.
2.
Build & Run
3.
수정을 확인 할 수 있는 화면으로 이동
4.
수정 확인
이 때 마지막 단계에서 수정이 정상적으로 되었으면 개발이 종료되고, 그렇지 않으면 다시 1번 부터 사이클이 반복됩니다. 예컨대 뱅크샐러드에서 “MY탭”화면의 “송금 버튼”이 안 보이는 이슈가 있다고 해봅시다. 이 이슈를 해결하기 위해선
1.
코드를 수정합니다.
2.
Build&Run
3.
앱 런칭 -> 송금이 활성화된 계정으로 로그인 -> 4번째 탭으로 이동
4.
“송금 버튼”있는지 확인
이라는 사이클을 겪어야 합니다.
글의 간결함을 위해 간단한 사례를 적었지만, 많은 경우 3번째 스텝에서 아주 많은 탭과 스와이프가 필요한 경우도 많습니다. 하지만 이 3번째 스텝은 얼마든지 XCUITest가 대신해 줄 수 있는 좋은 일거리입니다.
let app = XCUIApplication()
app.launch()
// 송금 기능이 활성화된 유저로 로그인 되었던 상태임을 가정
// 해당 유저의 비밀번호 입력
app.buttons["0"].tap()
app.buttons["0"].tap()
app.buttons["0"].tap()
app.buttons["0"].tap()
app.tabBar.buttons["MY"].tap()
Swift
복사
사이트에서 이 블록을 사용하려면 편집기에서 Stripe에 연결하세요.글 편집
// .gitignore 내에 다음을 추가합니다.DeveloperTest.swift
이렇게 테스트를 작성한 뒤에는, 개발 사이클이 다음과 같이 바뀝니다.
1. 코드 수정2. 마지막에 실행한 테스트 실행3. 수정확인
주의 할 점은, 기본적으로 XCUITest는 모든 테스트코드를 실행하고 나면 앱을 종료시킨다는 점입니다. 이를 방지하기 위해 DeveloperTest를 실행할 때는, 해당 DeveloperTest의 맨 마지막 줄에는 breakPoint를 걸어줍니다. 이 때의 breakPoint는 “UITest”실행에 대한 breakPoint이기 때문에 실제 개발중인 “앱 프로세스”에는 breakPoint가 걸리지 않습니다.
개발 내용을 확인하기
그런데 여기서 한 걸음 더 나아갈 수도 있습니다. 사실은 대부분의 경우 “수정 확인”에 대한 부분도 DeveloperTest에 추가 할 수 있습니다. 앞에서 사용한 “송금 버튼 안 보이는 이슈”를 예로 들면, 다음과 같은 Assertion 코드를 추가하면 마지막 “검증” 스텝까지도 자동화 시킬 수 있습니다.“`
let app = XCUIApplication()
app.launch()
// … 이동하는 코드
XCTAssert(app.buttons["송금"].waitForExistence(timeout: 10))
Swift
복사
이렇게 Assertion까지 추가되면 경우에 따라 이 DeveloperTest는 Regression을 방지 할 수 있는, 어엿한 UITest로 거듭나게 될 수 있습니다.
정리
DeveloperTest는 gitignore되기 때문에 일반적인 UITest에 비해 다음의 장점을 지닙니다.
•
해당 이슈를 재현하기 위해 id/pw등의 개인정보가 필요한 경우에, 이 정보를 활용해 테스트를 작성 할 수 있습니다.
•
setup 코드가 필요 없습니다.일반적인 UI테스트는 제대로 돌아가기 위해서는 적지 않은 setup 코드가 필요합니다. (예: 앱이 처음 설치된 상태에서 시작해야만 함, 특정 계정으로 로그인 된 상황에서만 실행되어야 함 등) 이런 모든 요건이 DeveloperTest에서는 필요 없습니다. 언제나 안정적으로 실행되어야 하는 UITest와는 달리, DeveloperTest는 지금 이 순간에만 잘 실행되면 그만이기 때문입니다.
•
비효율적으로 짜도 괜찮습니다.내 컴퓨터에서 잠시만 돌아가는 테스트이기 때문입니다. 특히 UI테스트 프레임워크에 아직 익숙하지 않을 때, 먼저 DeveloperTest를 많이 작성함으로써 여러 API들에 익숙해 질 수 있습니다.
무엇보다도, DeveloperTest는, 개발기간 동안에는 “더 빠른 개발을 위해” 작성했다가도, 그 개발이 끝났을 때 높은 확률로 “실제 CI에서 쓰일 수 있는 UI테스트”가 될 가능성이 높습니다. 이렇게 개발기간에 편의를 위해 만든 테스트를 조금만 수정해 프로그램의 안정성을 보장하는 테스트로 만드는 사이클이 계속된다면 아주 적은 노력으로도 빠른 시간 안에 코드베이스의 대부분을 커버하는 TestSuite가 만들어질 수 있을 것입니다.