<div id="readability-page-1" class="page"><div id="overflow-container" role="main">
		<article>
		
				<div>
						
<p>XCUITest를 활용해 안정적으로 돌아가는 테스트를 작성하기는 참 어렵습니다. 그러다보니 “XCUITest는 제대로 된 테스트 툴이 아니군! 다시는 쳐다보지도 말아야지”라는 생각을 하게 되는 분들도 많은 것 같습니다.</p>



<p>하지만 XCUITest을 기본적으로 “내 대신 눌러야 할 버튼들을 대신 눌러주는 로봇”으로 보게 된다면, 꼭 테스트를 위한 용도가 아니더라도 일상적인 업무 플로우를 훨씬 빠르게 만들어주는 훌륭한 툴이 될 수도 있습니다.</p>



<p>즉, 꼭 CI에서 돌아가는 테스트를 작성하기 위해서가 아니더라도,</p>



<ul><li>내가 개발중인 화면으로 빠르게 이동하는</li><li>내가 개발한 내용이 잘 적용되었는지를 확인하는</li></ul>



<p>정도의 용도로만 XCUITest를 활용해도, 훨씬 더 개발사이클을 빠르게 만들 수 있습니다. 이런 용도로만 사용하는 UITest들을 DeveloperTest라고 부르기도 합니다. (참조: <a href="https://www.youtube.com/watch?v=YzuJoVnxJCw&amp;t=1479s">DeveloperTest를 소개하는 영상</a>)</p>



<h2>DeveloperTest 추가하기</h2>



<p>프로젝트에 DeveloperTest를 추가하는 방법은 UITest를 추가하는 것과 같습니다. (참고: <a href="https://help.apple.com/xcode/mac/current/#/dev2ea31ea57">프로젝트에 UITest 타겟 추가하는 법</a>)</p>



<p>다만 <code>테스트가 작성되는 파일들이 .gitignore된다는 점</code> 만 다릅니다.</p>



<pre><code lang="vim">// .gitignore
DeveloperTests.swift</code></pre>







<h2>개발중인 화면으로 이동하기</h2>



<p>앱 개발의 일상적인 사이클은 다음과 같습니다.</p>



<ol><li>코드를 수정합니다.</li><li>Build &amp; Run</li><li>수정을 확인 할 수 있는 화면으로 이동</li><li>수정 확인</li></ol>



<p>이 때 마지막 단계에서 수정이 정상적으로 되었으면 개발이 종료되고, 그렇지 않으면 다시 1번 부터 사이클이 반복됩니다. 예컨대 뱅크샐러드에서 “MY탭”화면의 “송금 버튼”이 안 보이는 이슈가 있다고 해봅시다. 이 이슈를 해결하기 위해선</p>



<ol><li>코드를 수정합니다.</li><li>Build&amp;Run</li><li>앱 런칭 -&gt; 송금이 활성화된 계정으로 로그인 -&gt; 4번째 탭으로 이동</li><li>“송금 버튼”있는지 확인</li></ol>



<p>이라는 사이클을 겪어야 합니다.</p>



<p>글의 간결함을 위해 간단한 사례를 적었지만, 많은 경우 3번째 스텝에서 아주 많은 탭과 스와이프가 필요한 경우도 많습니다. 하지만 이 3번째 스텝은 얼마든지 XCUITest가 대신해 줄 수 있는 좋은 일거리입니다.</p>



<pre><code lang="swift">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()</code></pre>





<p>이렇게 테스트를 작성한 뒤에는, 개발 사이클이 다음과 같이 바뀝니다.</p>



<p>1. 코드 수정<br>2. 마지막에 실행한 테스트 실행<br>3. 수정확인</p>



<p>이렇게 되면 기존의 수많은 탭과 스와이프가 <a href="https://sarunw.com/posts/useful-xcode-shortcuts-for-unit-testing/#rerun-previous-test(s)" target="_blank" rel="noreferrer noopener">단축키 </a>한 번으로 끝나게 됩니다. </p>



<p>주의 할 점은, 기본적으로 XCUITest는 모든 테스트코드를 실행하고 나면 앱을 종료시킨다는 점입니다. 이를 방지하기 위해 DeveloperTest를 실행할 때는, 해당 DeveloperTest의 맨 마지막 줄에 다음과 같이 breakPoint를 걸어줍니다.</p>



<figure><img data-attachment-id="707" data-permalink="https://sungdoo.dev/programming/developer-ui-test/attachment/33e7bd72-ab92-448d-adf6-6f21a835cdb1/" data-orig-file="https://i0.wp.com/sungdoo.dev/wp-content/uploads/2021/01/33E7BD72-AB92-448D-ADF6-6F21A835CDB1.png?fit=1144%2C584&amp;ssl=1" data-orig-size="1144,584" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="33E7BD72-AB92-448D-ADF6-6F21A835CDB1" data-image-description="" data-medium-file="https://i0.wp.com/sungdoo.dev/wp-content/uploads/2021/01/33E7BD72-AB92-448D-ADF6-6F21A835CDB1.png?fit=300%2C153&amp;ssl=1" data-large-file="https://i0.wp.com/sungdoo.dev/wp-content/uploads/2021/01/33E7BD72-AB92-448D-ADF6-6F21A835CDB1.png?fit=1024%2C523&amp;ssl=1" loading="lazy" src="https://i0.wp.com/sungdoo.dev/wp-content/uploads/2021/01/33E7BD72-AB92-448D-ADF6-6F21A835CDB1.png?resize=700%2C357&amp;ssl=1" alt="" width="700" height="357" sizes="(max-width: 700px) 100vw, 700px" data-recalc-dims="1" data-lazy-srcset="https://i0.wp.com/sungdoo.dev/wp-content/uploads/2021/01/33E7BD72-AB92-448D-ADF6-6F21A835CDB1.png?resize=1024%2C523&amp;ssl=1 1024w, https://i0.wp.com/sungdoo.dev/wp-content/uploads/2021/01/33E7BD72-AB92-448D-ADF6-6F21A835CDB1.png?resize=300%2C153&amp;ssl=1 300w, https://i0.wp.com/sungdoo.dev/wp-content/uploads/2021/01/33E7BD72-AB92-448D-ADF6-6F21A835CDB1.png?resize=768%2C392&amp;ssl=1 768w, https://i0.wp.com/sungdoo.dev/wp-content/uploads/2021/01/33E7BD72-AB92-448D-ADF6-6F21A835CDB1.png?w=1144&amp;ssl=1 1144w" data-lazy-src="https://i0.wp.com/sungdoo.dev/wp-content/uploads/2021/01/33E7BD72-AB92-448D-ADF6-6F21A835CDB1.png?resize=700%2C357&amp;is-pending-load=1#038;ssl=1"></figure>



<p>이 breakPoint는 “UITest”실행에 대한 breakPoint이기 때문에 실제 개발중인 “앱 프로세스”에는 breakPoint가 걸리지 않습니다.</p>



<h2>개발 내용을 확인하기 </h2>



<p>그런데 여기서 한 걸음 더 나아갈 수도 있습니다. 사실은 대부분의 경우 “수정 확인”에 대한 부분도 DeveloperTest에 추가 할 수 있습니다. 앞에서 사용한 “송금 버튼 안 보이는 이슈”를 예로 들면, 다음과 같은 Assertion 코드를 추가하면 마지막 “검증” 스텝까지도 자동화 시킬 수 있습니다.<br>“`</p>



<pre><code lang="swift">let app = XCUIApplication()
app.launch()
// … 이동하는 코드
XCTAssert(app.buttons["송금"].waitForExistence(timeout: 10))</code></pre>



<p>이렇게 Assertion까지 추가되면 경우에 따라 이 DeveloperTest는 Regression을 방지 할 수 있는, 어엿한 UITest로 거듭나게 될 수 있습니다.</p>



<h2>정리</h2>



<p>DeveloperTest는 gitignore되기 때문에 일반적인 UITest에 비해 다음의 장점을 지닙니다.</p>



<ul><li>해당 이슈를 재현하기 위해 id/pw등의 개인정보가 필요한 경우에, 이 정보를 활용해 테스트를 작성 할 수 있습니다.</li><li><code>setup</code> 코드가 필요 없습니다.<br>일반적인 UI테스트는 제대로 돌아가기 위해서는 적지 않은 <code>setup</code> 코드가 필요합니다. (예: 앱이 처음 설치된 상태에서 시작해야만 함, 특정 계정으로 로그인 된 상황에서만 실행되어야 함 등) 이런 모든 요건이 DeveloperTest에서는 필요 없습니다. 언제나 안정적으로 실행되어야 하는 UITest와는 달리, DeveloperTest는 지금 이 순간에만 잘 실행되면 그만이기 때문입니다.</li><li>비효율적으로 짜도 괜찮습니다.<br>내 컴퓨터에서 잠시만 돌아가는 테스트이기 때문입니다. 특히 UI테스트 프레임워크에 아직 익숙하지 않을 때, 먼저 DeveloperTest를 많이 작성함으로써 여러 API들에 익숙해 질 수 있습니다.</li></ul>



<p>무엇보다도, DeveloperTest는, 개발기간 동안에는 “더 빠른 개발을 위해” 작성했다가도, 그 개발이 끝났을 때 높은 확률로 “실제 CI에서 쓰일 수 있는 UI테스트”가 될 가능성이 높습니다. 이렇게 개발기간에 편의를 위해 만든 테스트를 조금만 수정해 프로그램의 안정성을 보장하는 테스트로 만드는 사이클이 계속된다면 아주 적은 노력으로도 빠른 시간 안에 코드베이스의 대부분을 커버하는 TestSuite가 만들어질 수 있을 것입니다.</p>







<h2>참고 링크 </h2>



<ul><li><a href="https://www.youtube.com/watch?v=YzuJoVnxJCw" target="_blank" rel="noreferrer noopener">The Magic of UITesting</a></li><li><a href="https://www.hackingwithswift.com/articles/148/xcode-ui-testing-cheat-sheet" target="_blank" rel="noreferrer noopener">XCUITest Cheat Sheet</a></li><li><a href="https://developer.apple.com/videos/play/wwdc2015/406/" target="_blank" rel="noreferrer noopener">UITesting in Xcode</a></li></ul>

					</div>
		
	</article>
	
	
	</div></div>

Dev Story of Sungdoo

SungdooYoo

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

Developer UI Test를 소개합니다.

댓글