Xcode를 이용한 자동 테스팅 시작하기 파트 1/2

Charlie Fulton Charlie Fulton

이 포스트는 중국어 간체, 영어 언어로도 제공됩니다.

Learn how to add automated testing into your iOS 6 apps!
Ray로 부터 알림:  이 챕터는 iOS 6 Feast 의 마지막 iOS 6 튜토리얼이고 10번째이다! 이 튜토리얼은 새로운 책인 iOS 6 By Tutorials 에서 볼 수 있다. Charlie Fulton 이 이 챕터를 작성했다. 내 친구들 중의 한명이고 튜토리얼 팀의 새로운 멤버이다.  즐기자!
이 블로그 포스트는 iOS 튜토리얼 팀 멤버 Charlie Fulton가 작성했다. 그는 풀타임 iOS 개발자이면서 사냥, 낚시, 가족과 함께 어울리는 것을 즐긴다.

모든 개발자들은 자신의 소프트웨어를 테스트하고 스마트 사람들의 대부분은 이러한 목적으로 test suite를 만든다. test suite는 일반적으로 코드의 작은 단위, 특정 메서드나 클래스를 대상으로 단위 테스트로 알려진 테스트 케이스의 집합을 말한다.

단위 테스트는 테스트 주도 개발 방식을 채택하고 있어 코드가 아주 적은 버그를 가지고 있는지 확인 할 수 있다. 그리고 발견된 각 버그의 단위 테스트를 작성하여 버그가 절대발생되지 않을거라는 확신을 할 수 있다! 단위 테스트와 적극적으로 디버깅하면 애플리케이션 개발 환경에서 예상외의 동작의 가능성을 좁힐 수 있다.

알다시피 우리는 일을 끝내기 위해 종종 서두르다. 또는 우리는 게을러진다. 그래서 코드를 변경할 때마다 자동으로 실행하도록 단위 테스트를 자동화하는게 훨씬 좋다. 여러분이 팀의 일원으로 작업할 때 특히 중요하다.

자동으로 빌드, 테스트, 애플레키이션을 베타 테스터에게 배포할 수 있다면, 관심이 가지 않는가? 그러다면, 읽어주기 바란다!

보너스 절과 다음 절에서 자동 빌드 시스템을 셋팅하는 법을 배우고 iOS 앱에 대한 테스팅 시스템을 셋팅할 것이다. 예제 프로젝트를 통해 단위 테스트와 GitHub(github.com) 저장소에 리모트하는 법, Jenkins을 이용한 지속적인 통합 서버 구축을 진행한다. Jenkins은 점진적으로 여러분의 GitHub 저장소를 체크하고 빌드, 테스트, TestFlight에 앱을 전송할 것이다!

자동 테스팅에 대한 내용이 새롭다면 위에서 소개한 GihHub, Jenkins, TestFlight이 무엇인지 궁금할 것이다. 이 튜토리얼에서 각각의 내용에 대해 상세히 설명하지만 아래에 이 툴들에 대해 간략히 소개하겠다:

  • GitHub – 무료의 공공 Git 저장소, 공동작업자 관리, 이슈 트레킹, 위키, 다운로드, 코드 리뷰, 그래프 등 많은 기능을 지원한다!
  • Jenkins – 지속적인 통합 서버이며 Git 저장소의 내용이 변경되는 내용을 관찰하여 스케줄링한다. 그리고 빌드와 테스트를 자동으로 시작하고 결과를 알림으로 알려준다.
  • TestFlight – iOS 앱을 테스터들에게 Over the Air(OTA)로 전송하는 서비스, 크래쉬 로그 분석을 제공한다.

이 교육 오디세이에 대한 수단인 Geek스러운 예제 프로젝트를 소개할 수 있는 시간이 여러분을 잠시동안 벗어나게 해줄 것이다. 그러나 향후 페이지에 자세한 내용이 준비되어 있다!

GuildBrowser 소개

이 튜토리얼에서 Guild Browser라는 앱을 자동 빌드, 테스트 시스템을 구축할 것이다. GuildBrowser는 인기게임인 World of Warcraft를 위한 길드 멤버를 브라우즈하는 간단한 앱이다. 아래에서 볼 수 있듯이, UICollectionViewController에 있는 모든 멤버를 참조하는 렐름 이름과 길드를 입력할 수 있다:

이 앱은 블리자드의 WOW API를 이용했다. WOW API는 무료로 이용가능하다. RESTful로 만들어진 WOW API를  호출하기 위해 AFNetworking 프레임워크를 사용한다. 캐릭터 정보와 길드에 포함된 내용은 JSON 데이타로 반환된다.

이 게임을 플레이해보지 않았다면 다음 내용이 앱을 만드는데 도움이 될 것이다!

노트:  WOW API에 대한 자세한 내용은 Blizzard’s GitHub project (https://github.com/Blizzard/api-wow-docs)와 공식 WOW API 문서 (http://blizzard.github.com/api-wow-docs/)와   WOW 포럼에서 공헌한 커뮤니티 플랫폼 API(http://us.battle.net/wow/en/forum/2626217/) 에서 확인할 수 있다.

Git 시작하기

여러분이 요즘 코드에 대한 버전 관리의 어떤 것도 사용하지 않았다면 확실히 제대로 일은 안한것이다! 틀림없이 가장 인기있는 시스템은 지금 Git이다. 리누스 토발즈(리눅스를 만들었다.)가 리눅스 커널에 대한 코드를 관리하기 위해 이전의 SVN보다 더 나은 시스템으로 Git을 설계하고 개발했다. git은 좋은 소스 관리 시스템일 뿐 아니라 iOS 개발에 사용하기가 매우편리하게 직접 Xcode에 통합되어 있다.

 

Git은 “분산”버전 관리 시스템이며 Git 워킹 디렉토리는 자신의 저장소에 각각 존재한다. 중앙 시스템에 의존적이지 않다.

 

그러나 다른 개발자에게 로컬 저장소를 공유하기 위해 “remotes” 셋팅에서 연결을 정의할 수 있다. 원격 저장소는 일반적으로 중앙 원격 서버에 설정되어 있는 프로젝트의 버전이다. 이것은 심지어 Dropbox 폴더에 통해 공유할 수도 있다. (하지만 이것은 권장하지 않는다.)

 

지난 몇 년간에 Git 및 다른 분산형 버전 관리 시스템의 원격 저장소를 쉽게 설정하기 위한 다수의 서비스가 나타났다. Github은 이러한 서비스 중 가장 인기있는 서비스가 되었다. 그래서 좋은 이유이다.  이것은 무료의 공공 Git 저장소를 제공한다. 공동 작업자 관리, 이슈 트레킹, 위키, 다운로드, 코드 리뷰, 그래프 등… 기능도 제공하고 있다. 광고 같아 미안하지만 Github은 매우 굉장하다!

 

노트: Git에 대한 자세한 설명과 사용하는 방법은 How To Use Git Source Control with Xcode in iOS 6 튜토리얼에서 확인하기 바란다.  raywenderlich.com 에서 곧 나올것이다.

 

이 튜토리얼에서 GitHub에 원격저장소(짧게 repo 라 한다)를 셋팅하는 게 첫번째 작업이다. 이것은 원격 “origin”  저장소가 된다.  평상시처럼 로컬로 작업을 한 뒤 팀동료와 동기화하거나 새로운 테스터에게 보낼때 원격저장소(repo)에 모든 로컬 커밋을 push를 할 수 있다.

 

노트: 이 튜토리얼은 이미 GitHub 계정과 SSH 키 접근 설정이 되어 있다고 생각하고 작성했다. 만약 설정되어 있지 않다면, SSH key pair의 사용법과 생성하는 방법에 이 가이드(https://help.github.com/articles/generating-ssh-keys)를 참조하기 바란다. https URL에서 Github  사용자이름/비밀번호로 사용할 수 있지만 가이드에선 SSH 키 접근 설정이 되어있다고 가정한다.

 

첫째 command line tools이 설치되었는지 확인해야 한다.  Xcode/Preferences/Downloads 탭을 선택한다. 그리고 화면이 다음과 같은지 확인해라. (중요한 것은 Command Line Tools 옆에 Installed 가 표시되어야 한다.):

이 튜토리얼에는 스타터 프로젝트가 포함되어 있다. 프로젝트는 download here 할 수 있다. 원하는 하드디스크 위치에 프로젝트를 복사하고 Xcode 에서 GuildBrowser 프로젝트를 오픈한다.

GuildBrowser 앱은 ARC를 사용한  Single View Application template으로 만들어졌다. 그리고 단위 테스팅, 스토리보드, iPad-only, 로컬 Git 저장소를 사용한다.  기본 길드에 대한 몇몇 특징들을 보고 싶다면 컴파일하여 실행해보자.

브라우저를 열고 github.com 으로 이동해라 그리고 여러분의 계정으로 로그인해라. 계정이 없다면 만들어라. 그리고 오른쪽 위 코너에 있는 Create a New Repo 버튼을 클릭해라:

Repository name  Description fields 에 원하는 정보를 입력해라. – 이름은 Xcode 프로젝트의 이름과 일치할 필요는 없다. 그리고 Create repository 버튼을 클릭해라.

노트:  Initialize this repository with a README 박스를 체크하지 마라. 여러분은 빈 저장소를 원할 것이다. 그리고 다음으로 Xcode 프로젝트를 푸시할 것이다.

저장소 SSH URL을 복사하자.  copy to clipboard  버튼을 클릭하거나 ⌘-C 을 입력하면 복사된다. (먼저 SSH 버튼을 탭하여 SSH URL로 바꾸는 것을 명심하자).

이제 Organizer (Cmd-shift-2)을 열고 Repositories 탭을 선택한다.

GuildBrowser 프로젝트는 리스트의 아래에서 볼 수 있을 것이다.  Remotes 폴더를 클릭하고 Add Remote 버튼을 클릭한다.

Remote Name에 origin을 입력한다. 그리고 Location에 이전에 복사한 개인의 GitHub URL을 붙여넣는다:

Create를 클릭하면, Organizer는 다음과 같이 보일 것이다:

origin location에 입력된 패스워드가 없다는 것에 놀라지 마라.  Git’s SSH 접근을 사용한다. 그래서 패스워드가 필요없다.

이제 원격 저장소 설정이 완료되었다. 여려분의 모든 Xcode project에 이러한 단계를 통해 사용할 수 있다. 이것은 대단하다. 하지만 아직 로컬 Git 저장소에서 원격 Git 저장소로 아무것도 푸시하지 않았다. 이제 Xcode에서 시작해보자.

프로젝트로 돌아가서 먼저 로컬의 변경사항이 커밋되었는지 확인하자. 커밋을 하기 전까지 Xcode는 원격 저장소에 푸시하지 않는다. 다음 단계를 보자:

  1. FileSource ControlCommit (⌥⌘-C)로 이동하여 다음 화면에  “initial commit”와 같은커밋 메시지를 입력한다, 그리고  Commit을 클릭한다.
  2. 이제 원격 origin/master branch에 로컬 master branch를 푸시해야한다. FileSource ControlPush 로 이동한 뒤 Push를 클릭한다.
  3. 저장소에 푸시하는 처음 이후로 Remote 이름 옆에 origin/master 를 보게 될 것이다. Push 버튼을 눌러라. 그러면 Xcode가 나머지를 처리할 것이다.

push가 완료되면  브라우저로 돌아가 페이지를 refresh 한다. 그러면 GitHub 저장소에 변경된 내용이 커밋되어 있는 걸 볼 수 있을 것이다:

또한 OrganizerRepositoriesGuild Browser projectRemotes master branch에서 원격 저장소의 내용을 볼 수 있다:

축하한다, GitHub 원격 저장소에 로컬 Git 저장소를 연결 하는 법과 변경내용을 푸시하는 법을 알게되었다!

이제 GitHub 저장소가 설정되었으니 여러분의 저장소를 복제하거나 pull 요청을 수락하거나 코드를 보도록 다른 사람을 초대할 수 있다. 다른 사람이 GitHub origin/master 저장소에 푸시한 그들의 커밋 내용을 받을려면  FileSource ControlPull (⌥⌘-X)로 이동하라. 팝업에서 Remote에 origin/master를 설정하고  Choose를 선택하면 프로젝트에 변경된 내용에 추가될 것이다.

변경된 내용을 보려면 OrganizerRepositoriesGuildBrowser로 이동해라. 화살표를 눌러 내용을 펼친후 View Changes 버튼을 클릭한다.

지속적인 통합(Continuous integration)

 

지속적인 통합(CI)는 여러분의 코드를 버전 컨트롤 시스템에 대한 변경된 내용을 지속적으로 관찰하여 자동으로 빌드하고 테스트한다.(심지어 배포까지!)

CI는 프로젝트에 하루에 여러 번 변경하여 적용하는 많은 개발자들이 있을 때 정말 중요하다. 어떤 충돌이나 오류가 발생하면 모두에게 즉시 통보한다. 결국 누군가 빌드를 깨뜨린것이다!

Jenkins 만나기

Jenkins (http://jenkins-ci.org)은 오픈소스 CI 서버다. GitHub 원격 저장소에 푸시된 코드를 자동으로 빌드, 테스트 및 배포를 할 수 있도록 이 튜토리얼에서 사용할 것이다.

이번 절에서 Jenkins의 시작 및 작동에 대해 나머지 부분을 볼 것이다.

 

Jenkins 설치

Mac에 Jenkins를 설치하기 위해서 몇가지 방법이 있다:

  1. Jenkins 웹사이트에서 installer를 구해 설치할 수 있다. 이것은 데몬으로 실행하도록 Jenkins를 설정한다.  이것은 Max OS X 시작 시스템을 사용하도록 구성되어 있기 때문에 좋지만, 사용자가 제대로 작동하는Xcode 빌드를 얻기 위해 몇 가지 단계를 거쳐야될 것이다.
  2. 내장된 winstone 서블릿 컨테이너를 사용한다면 Jenkins을 WAR 파일(자바 아카이브 파일타입)로 터미널에서 실행할 수도 있다.
  3. 이미 Tomcat, JBoss 등이 설치되어 있다면 애플리케이션 컨테이너로 WAR 파일을 배포할 수 있다.

 

이 튜토리얼에서 터미널에서 Jenkins을 실행하겠다. 왜냐하면 이 방법이 가장 쉽고 빠르게 사용할 수 있기 때문이다. http://mirrors.jenkins-ci.org/war/latest/jenkins.war에서 Jenkins WAR 파일을 다운로드 받는다. Terminal 를 열고, 다음 명령어를 실행한다:

nohup java -jar ~/Downloads/jenkins.war --httpPort=8081 --ajp13Port=8010 > /tmp/jenkins.log 2>&1 &

노트: 위의 명령어는 Jenkins WAR 파일이 Downloads 폴더에 있다고 가정했다.  WAR 파일이 다른 위치에 존재한다면 그에 따라 명령어 path를 조절해야한다.

 

노트: Jenkins을 시작하기 위해 alias를 만드는 것이 유용할 수 있다. Terminal 이나 텍스트 에디터에서 숨김 파일을 보이도록 설정하여 /Users/(username)/.bash_profile 을 열고 다음 줄을 입력한다:

alias jenkins=”nohup java -jar ~/jenkins.war –httpPort=8081 –ajp13Port=8010 > /tmp/jenkins.log 2>&1 &”

.bash_profile을 저장하라. 그리고 새로운 Terminal을 열고 시작하기 위해 jenkins을 입력하라.

 

Jenkins 서버는 8081 포트로 시작한다. nohup 명령어는 UNIX 명령어로서 로그아웃하거나 shell이 끝나기 전까지 실행을 유지한다. – 이것은 “no hangup”을 의마한다.

 

또한 위의 명령어는 /tmp/jenkins.log 파일에 로그를 설정한다. 실행중인 서버와 충돌을 방지하기 위해 포트를 구성했다. Jenkins에 접속하려면 브라우저를 열어 다음 URL을 입력하면 된다:

http://localhost:8081/

 

 Jenkins 플러그인 설정

일을 설정하기 전에 Jenkins에 몇가지 기능을 추가해야 한다. Jenkins dashboard(via http://localhost:8081)를 열고 Manage JenkinsManage PluginsAvailable 탭을 클릭하라. 이용할 수 있는 많은 플러그인이 있다. 그래서 오른쪽 위에 있는 검색 박스를 통해 Git을 입력하여 필터링하자.

 

바로 이거다:

Check the box next to the Git Plugin 옆에 박스를 체크하고  Install without restart 버튼을 클릭하라. 인스톨이 완료되면 다음 화면을 볼 것이다:

이제 필터 검색 박사에 Chuck Norris를 입력하라. 그리고 Chuck Norris quote 플러그인을 찾아라. 이것은 이 튜토리얼을 위한 선택항목이지만 체크아웃을 권장한다! 설치하지 않는다면 그는 알게 될것이다! Chuck의 분노를 조심해라. :]

 

노트: 내 친구들은 나를 Charlie라 부른다. 하지만 내 진짜 이름은 Charles 이다. 나의 아버지의 중간 이름은 Norris이다.  그래서 내 아들 Chuck Norris Fulton의 하나를 이름에 대한 정당한 주장을 했다. 그러나 불행하게도 그녀는 허락하지 않았다. :]

 

 Jenkins 이메일 알림 셋팅하기

 

Jenkins이 빌드에러에 대한 알림을 보낼 수 있도록 SMTP 서버가 있는게 좋을 것이다. 하지만 SMTP 서버가 준비되어 있지 않다면 Gmail 계정을 사용할 수 있다. (또는 선호하는 다른 SMTP 서버를 사용해도 좋다.)

Manage JenkinsConfigure System 로 이동해서 Email Notification 색션에, 다음 셋팅내용을 입력하라. ( Advanced Settings 버튼을 누르면 몇가지 셋팅이 더 가능하다.):

 

  • SMTP Server : smtp.gmail.com
  • Sender Email address :
  • Use SMTP Authentication
  • User Name:
  • Password:
  • Use SSL
  • SMTP Port:465

이제 email 알림을 테스트 해보자. Test configuration by sending test-email을 체크한 뒤  email 주소를 입력하자. 그리고 Test configuration 버튼을 클릭하자. 테스트가 성공하면 변경된 설정을 저장하기 위해 Save 버튼을 누르는 것을 잊지 말자.

 

자 이제, 빌드 실패에 대한 내용을 Jenkins이 email로 보낼 것이다.

 

Jenkins job 생성하기

 

이제 Jenkins job 생성을 위해 준비하자! Jenkins dashboard를 열고 New Job을 클릭한다.  job name에GuildBrowser 를 입력하고  Build a free-style software project 라디오 버튼을 선택하자. 마지막으로 OK 버튼을 클릭하자. 일(job) 설정 화면이 보일 것이다.

 

Source Code Management 색션에서 Git 라디오 버튼을 클릭하고  Repository URL 텍스트 필드에 GitHub 원격 저장소 (origin/master) URL을 입력하자. 다음과 같이 보일 것이다:

Post-build Actions 색션으로 이동해서  Add post-build action 버튼을 클릭하여 Email Notification을 선택해라.  내용을 받을 사람들의  email 주소(들)을 입력해라. 마지막으로 Send email for every unstable build 체크해라. 다음과 같이 보일 것이다:

Chuck Norris 플러그인을 설치했다면 또한  post-build action에 Activate Chuck Norris를 추가할 수 있다. 하지만 그건 좀 끔직한 소리로 들린다! 걱정마라 빌드를 깨지는 않는다!!

 

노트: Chuck Norris는 오직 한 번만 개발하기 때문에 버전 넘버를 기록하지 않는다. 사용자가 버그를 보고하거라 기능 요청을 하는 경우, 그들은 일몰을 보지 못할 것이다. :]

 

Save 버튼을 클릭하는 것을 잊지말자.

 

왼쪽 사이드바에 Build Now 버튼을 클릭하여 GitHub 셋팅이 올바르게 되어 있는지 확인하자. job이 시작되면 Build History 박스에 업데이트 내용을 볼 수 있다:

모든게 잘 되었다면 빌드 #1 파란색으로 표시될 것이다. 성공했다는 것을 나타낸다:

정확히 빌드하는 동안 무슨 일이 있었는지 확인하려면 빌드위에 마우스를 올려놓고 Console Output를 눌러 확인해보자

콘솔 출력결과는 이렇게 보일 것이다. GitHub 저장소에 코드가 pull down이 성공적으로 되었다는 내용을 보여준다:

지금까지 job을 Github 연결과 email 알림 설정을 했다. 자 서둘러 흥미로운 것을 추가해보자: 테스팅, 빌딩, TestFlight에 업로드하는 것.

 

노트: Jenkins 프로 팁! 빨리 job 설정 화면으로 이동하려면 화면 위 탐색경로에서 job 이름위에 마우스를 올리고 메뉴에서 Configure 를 선택해라.  이 메뉴는 특히 콘솔 출력화면을 볼 때 유용하다

Jenkins으로 자동 xcodebuild하기

자 프로젝트를 빌드하기 위해 Jenkins job을 업데이트 해보자.  Jenkins DashboardGuildBrowser jobConfigure 로 이동한다.  Build 색션에서  Add build step 드롭다운을 클릭하여 Execute shell 을 선택하자.

Command 윈도우에 다음 코드를 입력한다:

 

export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer/
xcrun xcodebuild clean build

 

command 윈도우는 다음과 같이 보일 것이다:

자 이제 Save 를 클릭하자. Build Now를 클릭하여 다시 job을 테스트하자.  job이 실행될 때 주의 깊게 보자!  다음 화면을 보게 될 것이다.Jenkins이 코드에 대한 sign을 하기 위해 codesign 접근을 허락할 건지물어보는 내용이다.  Always Allow 를 선택하자.

prompt를 미스낸다면(예를들어 iPhone을 가지고 달아난 당신의 2살짜리 아이를 쫓을 때),   job의 콘솔 출력에 실패했다는 메시지를 보게 될 것이다.:

 

Command /usr/bin/codesign failed with exit code 1 ** BUILD FAILED ** The following build commands failed: CodeSign build/Release-iphoneos/GuildBroswer.app (1 failure) Build step ‘Execute shell’ marked build as failure

 

이러한 현상이 일어나면  job을 다시 시도해라. 이번에는 prompt를 미스내지 말자 (아니면 두살짜리 아들이 당신의 iPhone을 가지고 달아나게 냅두자.)  :]

 

이 feast 포스트를 작성할 때, 나는 내 아이폰을 찾기 위해 휴대 전화를 찾아 사용했다. 장난꾸러기가 장난감 차 트렁크에 넣어둔 아이폰을 찾았다!!

 

prompt 를 놓치지 않는다고 가정하고, 출력 메시지가 다음과 같이 보일 것이다:

 

/Users/charlie/.jenkins/workspace/GuildBrowser/build/Release-iphoneos/GuildBrowser.app Unable to validate your application. – (null)

 

위의 메시지는 빌드가 성공했다는 내용이다!  “unable to validate” 메시지는 무시해라. – 우리가 올해 WWDC에서 확인할 수 있는 알려진 버그이다.

 

노트: Jenkins 플러그인에는 iOS 앱 빌드를 위한 Xcodeplugin이 존재한다. 이 플러그인은 대단하지만 난 앱을 빌드할 때 어떤 일이 벌어지는지 정확히 이해하는 게 좋다고 생각한다. 몇가지 간단한 빌드 스크립트에 플러그인과 같은 결과를 얻을 수 있다.

또한 플러그인에 의존하는 것은 어떠한 위험을 초래할 수 있다. Apple이 플러그인을 깨고 어떠한 일을 바꾼다면 더 이상 업데이트 않는다면 어떠한 일에 대한 수단을 필요로 할 것이다.

 

단위 테스트

 

단위 테스트는 개발하는 내용처럼 코드 출력이 변하지 않는 것을 보장한다. 클래스의 동작에 대한 예상을 설정한 후 이러한 예상을 확인하는 단위 테스트를 작성한다. 또한 단위 테스트는 새로운 기능과 큰 변경 내용을 쉽게 개발하기 위해 결과를 단계적으로 보고 변경을 증가하도록 허락한다.

단위 테스트를 포함하는 프로젝트에 몇 가지 장점이 있다:

  • 신뢰성 – 좋은 테스트의 집합을 통해 가능한 적은 버그를 갖을 가능성이 가장 높다. 이 방법을 따라 새로운 약간의 코드 및모든 변경 사항를 확인하는 것과 처음부터 테스트한 개발 코드는 특히 정확하다.
  • 코드 신뢰 – 가동중인 단위 테스트들로 많은 양의 코드(알다시피, 코드는 같은 결과를 만들어 테스트를 통과해야 한다.)를 리펙터할 때 우왕좌왕 하는 게 적다.
  • 안정성 – 버그가 발견되면 새로운 테스트는 버그가 다시 괴롭히지 않는 보장을 추가 할 수 있다.

 

Xcode는 단위 테스트를 지원하기 위해 SenTestingKit 프레임워크가 내장되어 있다. 단위 테스트를 작성할 때 두가지 단어의 의미를 알아야한다:

 

  • Test case – 단위 테스트의 가장 작은 구성 요소는 테스트 케이스이다. 코드의 단위가 생산하는 것에 대한 기대를 확인한다. 예를 들어, 테스트 케이스는 단일 메서드 또는 클래스 메서드의 작은 그룹의 테스트에 초점을 잡을 수 있다. Xcode에서, 모든 테스트 케이스는 이름이 test로 시작한다. 아래의 예에서 볼 수 있다.
  • Test Suite – 테스트 케이스의 그룹. 보통 특정 클래스에 대한 테스트 케이스의 그룹이다. Xcode에서 Objective-C test case class 이름의 test suite를 만들기 위한 템플릿이 존재한다. 이것은 SenTestCase 의 서브클래스인 클래스를 생산한다.

 

단위 테스트를 설정하는 두 가지 일반적인 방법이 있다: bottom up(개별적으로 각 메서드/클래스를 테스트) 또는 top down(전체 앱의 기능 테스트)으로 테스트를 진핼 할 수 있다. 두 접근 방법은 중요하다 –  이 두 방법의 조합을 사용하면 좋다.

 

이 튜토리얼은 모델 클래스에 초점을 맞춰 bottom up 테스트를 진행한다.  iOS 6 by Tutorials에 다른 챕터에서 top down 테스트와 유저 인터페이스에서 UI Automation의 모델 코드까지 다룰 것이다.

 

애플리케이션 vs. 로직 테스트 타켓

 

다음은 Xcode에서 이용할 수 있는 단위 테스트의 두가지 차이점에 대해 보도록 하자.
애플리케이션 단위 테스트

애플리케이션 단위 테스트는 기본적으로 UIKit에서 어떤 기능을 위한 코드 또는 실제 호스트 앱의 컨텍스트에서 실행을 위한 필요한 것을 말한다. 단위 테스트를 포함한 새로운 프로젝트를 생성할 때 기본적으로 생성되는 단위 테스트 타켓의 유형이다.

 

타켓의 모든 코드는 앱 번들에서 실행된다.  각각의 타켓의 빌드 설정과 Test Host 와 Bundle Loader의 셋팅의 설정을 확인하여 차이점을 볼 수 있다:

로직 단위 테스트

커멘트 라인에서 코드의 단위를 실행할 수 있는 유일한 단위 테스트이다.  이 코드는 앱에서 분리되어 테스트된다.

기본적으로시뮬레이터에서 실행하지 않고 자신의 코드를 테스트하는 단위 테스트이다. 이것은 커스텀 로직, 네트워크 액세스 코드 또는 데이터 모델 클래스들을 테스트하기 적합하다.

command line notes에서 테스트 실행 – 실행하지마라!

 

안타깝게도  Xcode 4.5에서 xcodebuild 명령어를 이용한 단위 테스트를 실행하는 것은 아직 “공식적으로” 지원되지 않는다. 이것은 매우 실망스럽게 한다. 왜냐하면 명백히 Xcode에서 애플리케이션 단위 테스트를 실행할 수 있기 때문이다. 이러한 이유로 다음 색션에서 특별한 로직 테스트 타켓을 만들 것이다.

몇몇 크리에이티브한 개발자가 Xcode.app 컨텐츠에 테스팅 스크립트 패치를 만들었다. 이 튜토리얼에서는 Jenkins의 로직 테스트와 Xcode의 애플리케이션 테스트에 집중한다. 패치를 원한다면, 다음 파일을 살짝 보도록 하자:

 

/Applications/Xcode.app/Contents/Developer/Tools/RunUnitTests
/Applications/Xcode.app/Contents/Developer/Tools/RunPlatformUnitTests.include

 

이 스크립트는 ⌘-U를 눌러 단위 테스트를 실행할 때 기본적으로 실행되는 내용이다:

 

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Tools/RunPlatformUnitTests

 

여기서 명렁어 라인에서 시뮬레이터에 애플리케이션 단위 테스트를 할 수 없다는 메시지를 볼 것이다. (Xcode에서 이 작업은 잘 작동된다):

 

RunTestsForApplication() { Warning ${LINENO} “Skipping tests; the iPhoneSimulator platform does not currently support application-hosted tests (TEST_HOST set).” }

 

몇몇 영리한 해커들은 작업을 위해 애플리케이션 테스트를 사용했다.  하지만 스크립트를 Xcode 4.4에서 4.5로 해야한다. 이것에 대한 위험은 사용자 본인이 감수해야 한다.

 

로직 단위 테스트 타켓 추가하기

 

이제 빌드 스크립트에서 호출할 수 있는 새로운 테스트 타켓을 만들어보자. Xcode에서 FileNewTarget…iOSOtherCocoa Touch Unit Testing Bundle 로 이동하여  Next 를 클릭한다.

Tests로 끝나는 이름을 입력해라 예를들어 GuildBrowserLogicTests 와 같이 입력해라.  Use Automatic Reference Counting 이 체크되어 있는지 확인해라.  그리고 Finish 를 클릭한다.

이제 같은 이름으로 새로운 스킴을 구성하자. 모든 작업이 잘 작동하는지 테스트하기 위해 새로운 스킴(Xcode 툴바 Run과 Stop 버튼 옆에 스킴 셀랙터를 사용하자)으로 바꾸고 ProductTest (⌘-U) 를 실행하자. 빌드는 성공적으로 되지만 테스트는 실패할 것이다.

에러 메시지에 표시된 것처럼, 단위 테스트가 아직 구현되지 않았기 때문에 발생되었다. 이것을 고쳐보자!

 

첫째, 하이라이트된 GuildBrowserLogicTest.h 와 GuildBrowserLogicTest.m 기본 테스트 클래스를 지우자.   Delete 를 누리고,  Move to Trash 를 선택한다.

 

스킴을 바꾸는 걸 필요로 하지 않기 위해서 ProductTest 를 실행할 때 새로운 타켓을 포함을 위해 메인 앱 스킴 GuildBrowser를 수정하자.

GuildBrowser 스킴으로 바꾸고 ProductEdit Scheme (or you can simply Alt-click on the Run button)을 눌러 스킴을 수정한다. scheme editor에서, 하이라이트된 Test 설정에서 + button를 눌러 새로운 타켓을 추가하고, 윈도우에서 GuildBrowserLogicTests 선택한다. 그리고 Add 를 누른다..

화면이 다음과 같이 보일 것이다:

이제 테스트 타켓에 단위 테스트 클래스를 추가할 수 있다. 그러면 jenkins job에서 이 타켓을 호출할 수 있다.

이 feast는 다음 연재에서 꼭 실행하겠다! 항상 갈망해라.. 에러에 굶주려라!

 

어디로 가야하나?

며칠내에 우리는 이 튜토리얼의 2부를 게시할 것이다. 그 동안에  질문이나 의견이 있으면 아래의 포럼에 참여바란다!
이 블로그 포스트는 iOS 튜토리얼 팀 멤버 Charlie Fulton가 작성했다. 그는 풀타임 iOS 개발자이면서 사냥, 낚시, 가족과 함께 어울리는 것을 즐긴다.

Charlie Fulton
Charlie Fulton

Charlie Fulton is a full time iOS developer. He has worked with many languages and technologies in the past 16 years, and is currently specializing in iOS and Cocos2D development. In his spare time, Charlie enjoys hunting, fishing, and hanging out with his family.

You can follow Charlie on Twitter.

User Comments

0 Comment

Other Items of Interest

Ray의 월간 뉴스레터

Sign up to receive a monthly newsletter with my favorite dev links, and receive a free epic-length tutorial as a bonus!

Advertise with Us!

Hang Out With Us!

Every month, we have a free live Tech Talk - come hang out with us!


Coming up in May: Procedural Level Generation in Games with Kim Pedersen.

Sign Up - May

Coming up in June: WWDC Keynote - Podcasters React! with the podcasting team.

Sign Up - June

Vote For Our Next Book!

Help us choose the topic for our next book we write! (Choose up to three topics.)

    Loading ... Loading ...

Our Books

Our Team

Tutorial Team

  • Toby Stephens

... 55 total!

Editorial Team

... 21 total!

Code Team

  • Orta Therox

... 1 total!

번역 팀

  • Vitaliy Zarubin

... 38 total!

Subject Matter Experts

  • Richard Casey

... 4 total!