BLOG main image
분류 전체보기 (92)
Cocoa Touch (11)
Cocoa (10)
Objective-C (13)
Swift (6)
Development (11)
Tools (11)
Books (7)
etc (21)
Application release (1)
Document Project (1)
105,799 Visitors up to today!
Today 2 hit, Yesterday 2 hit
daisy rss
tistory 티스토리 가입하기!
'Xcode'에 해당되는 글 4건
2013. 7. 10. 21:43

프로그래밍을 할때 TDD로 하든 그렇지 않든 UnitTest를 돌리는 것은 매우 유용합니다.

애플에서도 간단한 가이드로 유닛테스트 방법을 알려주고는 있는데 test coverage를 쉽게 볼 수 있는 방법은 없습니다. coverage가 제대로 확인되지 않으면 정확히 어디가 테스트 되었는지 어디가 테스트 되지 않았는지 판별하기 어렵고 제대로 된 테스트를 만들기 쉽지 않습니다.

그럴때 사용할 수 있는 툴로 CoverStory라는 툴이 있지만 테스트 후 매번 수작업으로 확인해줘야 하는 불편함이 있습니다. 특히 TDD를 한다던지 해서 테스트 수행횟수가 지극히 많을 때는 무척 불편해집니다.

이때 사용할 수 있는 간단한 팁입니다.

(주의. test target구성이나 test coverage file 생성을 위한 옵션 설정에 대한 설명은 뺍니다. 구글링 해보시면...)


먼저 Edit Scheme을 선택해서 테스트 타겟의 scheme을 확인합니다.

Test항목에서 Pre-actions를 다음과 같이 스크립트를 추가합니다. 이 부분을 빠트리면 실행횟수가 계속 누적됩니다.


find "${TARGET_TEMP_DIR}" -name "*.gcda" -exec rm {} \;


다음 Post-actions에 다음 내용의 스크립트를 추가합니다.


/usr/bin/osascript <<-EOF

try

tell application "CoverStory"

activate

open "${TARGET_TEMP_DIR}"

end tell


tell application "System Events" to keystroke "r" using {command down}


on error err_msg number err_num

return null

end try

EOF


그리고 나서 테스트를 수행하면 (당연히 CoverStory는 설치되어 있어야 합니다.) 자동으로 CoverStory가 열리면서 test coverage를 보여줍니다.


이상 불친절한 팁 끝.

Name
Password
Homepage
Secret
2010. 10. 17. 17:36
타겟을 여러개 만들고 각각의 info.plist가 조금씩 다른데 하나만 관리하고 싶다면 info.plist에 preprocessor를 사용하는 것이 좋다.
이때 빌드 옵션에서 Process Info.plist File을 채크해주고 Info.plist Preprocessor Definitions에 definition값을 넣어주면 된다.
한가지 안타까운 점이라면 이렇게 해서 info.plist를 편집하면 info.plist 에디터에서는 그 내용이 안보이는듯... 정확하게 기억하고 있지 않으면 실수하기 쉬울듯...
whatisid | 2011.02.07 17:59 | PERMALINK | EDIT/DEL | REPLY
오랜만에 들어왔는데 10월에 딱 제가 한 거랑 같은 거라서 반가운(?) 마음에 덧글 답니다.
Lite 버전과 정식버전을 따로 유지하는 삽질을 바로 이 info.plist의 preprocessor 통해서 하나로 합쳐서 속이 다 시원했던 기억이 ㅎㅎㅎ
maccrazy | 2011.02.08 23:23 신고 | PERMALINK | EDIT/DEL
:) 안녕하세요. 이 방법도 좋긴 한데 공동작업에서는 plist 에디터에서 그 내용들이 제대로 표현이 안되어서 그냥 빌드옵션 잘 손봐서 우회해서 쓰고 있습니다. 두 방법을 두고 한참 이야기 해본 결과 아무래도 공동작업시 실수할 확률이 높아서 말이죠... 그나저나 잘 지내시죠?
Name
Password
Homepage
Secret
2010. 10. 13. 13:59
Build and Archive가 제대로 동작하지 않고 "The operation couldn't be completed. No such file or directory"라는 메시지를 내놓을 때가 있습니다.
뭐가 문제일까 싶어서 프로젝트 명도 바꿔보고 (프로젝트 명과 빌드된 결과물의 이름이 달라서...) 별 짓 다 해봤는데 안되더군요. 그런데 알과봤더니 타겟의 옵션을 바꿔주면 되는 문제였습니다.

"Generate Debug Symbols"가 꺼져있으면 이런 에러 메시지를 보여주네요. 참 불친절한 메시지가 아닐 수 없습니다. T_T
박종암 | 2010.10.15 04:57 | PERMALINK | EDIT/DEL | REPLY
잘못된 메시지군요. "해당 파일이나 디렉토리가 없다"라면, 해당 파일이나 디렉토리가 없어야 하는데, 변수이름이나 메소드 이름같은 것을 찾을 수없는 상황에서 나오나보지요?

요새 정말.. Apple...
maccrazy | 2010.10.18 12:35 신고 | PERMALINK | EDIT/DEL
요즘 애플... 디테일이 좀 떨어지죠... 왜 그러나 모르겠어요... T_T
Name
Password
Homepage
Secret
2008. 8. 29. 23:33
리팩토링은 개발의 전 과정에 있어서 끊임없이 지속되어야 하는 작업이라는 것이 필자의 생각이다. 그 만큼 개발자들은 리팩토링에 많은 시간을 사용하고 있다고 봐야 할텐데 사실 이 작업을 함에 있어서 도구를 사용하는데 인색한 것도 사실이다.
어쩌면, 도구를 사용하기 싫어서라기 보다 마땅한 도구가 없기 때문일 수도 있다. 우리가 주로 사용하는 리팩토링 도구들은 어떤게 있을까? find/replace, copy&paste 그리고 수많은 단순 작업들이 아닌가? 심지어 유닛테스트 마저 제대로 갖춰놓지 않아서 매번 리팩토링 후에 일일이 손으로 테스트하고 있지는 않는가?

Xcode에는 오래 전 부터 리팩토링을 도와주는 툴이 존재했다. Edit 메뉴의 Refactor... 메뉴가 그것인데 사실 나도 잘 사용해본 적이 없었다. 이상하리만치 그런 작업은 일일이 눈과 손에 의존 해서 처리해야 실수가 적다는 근거없는 맹신 때문이었을 수도 있다. 요즘 시간에 좀 여유가 생긴 덕분에 그 툴에 대해서 조금이나마 들여다볼 기회가 생겼다.

먼저 Refactoring 툴의 기능을 확인 해보면 아래와 같은 것들이 지원됨을 알 수 있다.
  • Rename
  • Extract
  • Create Superclass of
  • Move Up
  • Move Down
  • Encapsulate
  • Modernize Loop
위의 모든 내용을 다 테스트 해보지는 못했다. 뭐, 특별한 것은 없을 듯 하다.

먼저 rename의 경우 기존의 작업 방식대로 할라치면 find - review - replace의 연속 작업이 될 것이다. 물론 Xcode가 지원하는 Find in project... 기능을 사용핱텐데 필자는 가끔 귀찮으면 선언부만 rename하고 바로 빌드 해버리는 무식한 짓도 서슴치 않는다. 다행이 요즘 컴퓨터들은 속도가 무척 빨라서 어떤 툴 보다 빨리 문제가 있는 부분들의 목록을 뽑아준다. :(
(결코 권하고 싶은 방법은 아니다...) 하여튼, 이 대책없는 작업을 refactor툴은 어느 정도 품위있게 할 수 있게 도와준다.
변경할 새 이름을 넣고 review를 누르면 각 파일별로 어느 위치에서 뭐가 수정되었는지 보여주는데 File Merge툴과 유사한 방법으로 사용 할 수 있다.
좋다. 참 마음에 들었다. 한가지 버그를 발견 하기 전 까지는... 문제는 클래스 이름을 수정하고 연관된 파일명까지 수정하라고 옵션을 줬을때 다른 파일에서 import문 안에 있는 파일 명을 찾아서 고쳐주지 못하는 문제가 발생했다. 당연히 컴파일 할때 에러 대량 발생... 그래, 뭐, 컴파일 할 때라도 알 수 있으니 다행이라 생각하자.

다음 테스트 해본 기능은 Create Superclass of이다. 현재 내가 선택한 클래스의 슈퍼클래스를 만드는 기능인데 사실 별로 힘든 작업이 아닌데 굳이 툴의 도움을 받아야 할지 의문이다. 차라리 흩어진 여러 클래스들의 공통 슈퍼클래스를 만들고 공통적인 변수들이나 메소드들을 끌어 올릴 수 있는 기능이라면 모를까... 하여간 이 기능은 별것 아닌데서 또 문제를 일으켰다. 작업 중 크래쉬... 결국 다시 Xcode를 띄운 후 Xcode가 생성해놓은 마무리 못지은 파일을 삭제하고 다시 시도 후 성공... 그러나 또 문제가 생겼다. 슈퍼클래스의 부모가 NSObject가 되는 상황인데 위에 딸랑 #import "NSObject.h" 이렇게 해놓은게 아닌가? 당연히 컴파일 에러 발생. 결국 손으로 #import <Cocoa/Cocoa.h>로 고친 후에 빌드에 성공 할 수 있었다.

사용자 삽입 이미지
Create Superclass of 실행 화면

이쯤 되니 슬슬 내가 이 툴을 왜 테스트 하고 있는지 의심이 들기 시작했다. 이거 쓸만한거 맞긴 한건가... 하지만 몇개만 더 해보기로 했다 이번 테스트 항목은 Move Up. 특정 변수를 선택해서 그 변수와 연관된 함수를 슈퍼클래스로 옮길 수 있게 해준다. 뭐, 얼마나 유용한지는 여전히 의문이지만 한번 해보기로 했다. 변수와 관련된 억세스 메소드(accessor)가 슈퍼클래스로 잘 옮겨 갔다. 뭐.. 그냥 그냥 되는구나. Move Down은 역시 비슷할듯 해서 생략했다.

자 하나만 더 해보자. Encapsulate. Modernize Loop의 경우 fast enumeration으로 바꿔주는 기능인데 필자가 아직은 잘 사용하지 않는 기능이니 생략하기로 했다. 특정 변수를 선택해서 encapsulate를 선택하니 먼저 그 변수의 억세스 메소드(accessor)를 만들어 주고 그 변수를 사용하는 모든 곳에서 억세스 메소드만 사용하게 코드를 수정해 줬다. 다 좋다. 그런데 그 변수를 가지는 객체 자체에서 사용하는 것 마저 억세스 메소드 호출로 바꿔버렸다. 뭐, 자주 그렇게 쓰기도 한다. 하지만 init, dealloc에 있는 변수마저 그렇게 해버리면... 코드 읽기가 대략 난감 해지는 상황이다. :(
사용자 삽입 이미지
Encapsulate 실행 화면

Refactor 툴이 소개된게 2006년 WWDC에서이다. 뭐, 그때에 비해서 많이 향상 된것 같으나 아직 신뢰하면서 쓰기엔 2% 부족한 툴이 아닌가 싶다. 물론 빠르게 리팩토링을 진행함에 있어서 도움이 될 부분이 분명히 있을 것이다. 하지만, 프로그래밍이란 매우 신중한 작업이라는 점을 고려한다면 여전히 메이저 툴로서 자리 잡기에는 불안한 요소가 많이 있지 않나 싶다. 유닛 테스트 툴의 발전 속도에 비해서 리팩토링 툴의 발전 속도가 더딘 것이 당연한 것인지도 모르겠지만 말이다.
박종암 | 2008.09.03 04:41 | PERMALINK | EDIT/DEL | REPLY
저는 이 refactoring 기능을 사람들이 많이 쓰면 좋겠다싶은 면이 있어요. 그건 자동화를 해주기 때문이 아니고, 다른 사람이 쓴 코드를 척 보고 알 수있는, 정형화된 코드를 만들어주기 때문에 그렇습니다. 저희 회사 코드를 보다보면.. 아무래도 기술적 백그라운드가 다 다르다보니..
전자과 출신들은 "돌아가서 문제가 해결되면 되는 코드"에 치중을 하다보니, 코드의 관리성, 유연성은 무시하는 코드를 만든다는 것을 알게 되더군요. 그 사람들에게 이런 코드는 이래서 잘못이다라고 설명하면 이해를 못합니다. 제대로 돌아가고 제대로 된 값이 나오면 "맞는 코드"죠. 즉 그들이 잘못되었다는게 아니라, 생각하는 범주가 틀리다는거죠.

아직 Xcode 3.1이 문제가 자잘하게 많이 있는거 같습니다.
빨리 좀 좋아지길 바래요.
Name
Password
Homepage
Secret
prev"" #1 next