TDD 관련 아티클을 정리하고 있는데 오늘로서 완료할 것 같네요.

이 글을 읽고 TDD 에 대해서 많이 개념이 잡힌것 같습니다.

TDD from starting from user stories - a top-down style 03

A sample

실제 샘플 코드를 한번 보죠. 웹 어플리케이션 관련 작업을 하고 있다고 가정해 봅시다. 여기 로그인 기능과 관련한 스토리가 있습니다.

유저가 웹 사이트에 로그인하려고 합니다. 이 때 그 유저는 등록된 유저를 위한 어떤 기능을 사용할 수 있게 됩니다.

이 스토리에 대한 acceptance criteria 를 보면

* Happy path: 성공적인 로그인
Given: 유저가 로그인 페이지로 감
When: 제대로 된 아이디와 패스워드를 입력하고 submit 함
Then: 유저는 성공했다는 메세지와 함께 로그인 하게 됨

* Username or password missing
Given: 유저가 로그인 페이지로 감
When: 아이디나 비밀번호를 입력하지 않고 submit 버튼을 누름
Then: 유저는 "username or password missing" 이라는 에러 메세지를 보게 됨

* Username or password incorrect
Given: 유저가 로그인 페이지로 감
When: 맞지 않는 아이디나 비밀번호를 입력하고 submit 버튼을 누름
Then:  유저는 “username or password is not correct” 라는 에러 메세지를 보게 됨

TDD from starting from user stories - a top-down style 02

Pros and Cons

Pros

acceptance test를 먼저하면 개발자는 코딩을 시작하기 전에 value에 대해 좀 더 생각할 수 있습니다.

여러분이 무엇을 테스트할지 정확하게 이해하지 않은 상태에서 acceptance test를 먼저 만드는 것은 정말 어렵습니다. writing test first라는 룰을 곧이 곧대로 적용하도록 하면 코딩을 하기 전에 business requirement 에 대해 개발자들이 좀 더 생각할 수 있도록 도와 줄 수 있습니다. 이 접근법은 개발자들이 business analyst들이나 고객을 직접 접촉해서 business를 먼저 이해하도록 독려할 수 있습니다. 그렇게 함으로서 요구 조건을 잘 못 이해하는 경우를 줄일 수 있고 현업(business people)과 개발팀 사이의 인식 차이도 줄일 수 있습니다.

Test automation은 프로젝트이 시작단계에서 부터 시작해야 합니다.

TDD 가 acceptance test부터 시작한다는 것은 모든 테스트에 대한 automation이 그 프로젝트 그 자체임을 암시합니다. 왜냐하면 자동적으로 프로젝트를 빌드하고 테스트들을 run 하는 작업 없이 빠른 feedback을 얻기는 불가능하기 때문이죠. CruiseControl같은 integration 툴들을 사용함으로서 이런 작업을 보다 쉽게 할 수 있습니다.

Clear and simple design, testable code

전에 얘기 했듯이 story와 acceptance criteria 의 business value 를 분명하게 이해해야 합니다. 그리고 나서 그것들을 가지고 테스트를 해야 합니다. 이제 남은 일은 이 테스트들이 pass 하도록 하기 위한 가장 간단한 코드를 만드는 겁니다. 만약 writing unit tests first 가 클래스의 각 public 인터페이스의 간단한 디자인을 얻는데 도움을 줄 수 있다면 writing functional tests first 는 business value를 implement 하기 위한 가장 간단한 디자인을 할 수 있도록 도움을 줍니다.

Tests as documents

TDD를 통해 얻을 수 있는 것 중 하나는 프로젝트의 documentation 역할을 할 수 있는 좋은 test들의 세트를 가질 수 있다는 겁니다. 수준 높은 functional test들을 가진다는 것은 모두에게 businiss requirement를 이해하는데 도움을 주고 이 functional test들을 단순히 수행함으로서 어플리케이션의 functionality 를 이해하는데 도움을 줄 수 있습니다.

technical people 들만 이해할 수 있는 우리의 test들을 non-technical people들도 이해할 수 있도록 translate 해 주는 툴들도 있습니다. (Testdox 같은). rspec 같은 testing framework들은 이런 종류의 일을 지원하는 built-in 기능이 있습니다. 그리고 rbhave와 jbehave 같은 다른 프레임워크들도 business natural language에 의해 그러한 기능들을 제공합니다. 이런 일들을 통해 우리의 test들은 business value를 좀 더 제대로 반영할 수 있고 이해하기도 쉽습니다.

Delay the implementing and design decision

테스트들을 보고 개발자들은 implementation을 수행하고 design을 결정하는 일을 진행할 수 있습니다.

nurture the good habits of programming

개발자들은 코딩이나 기술적인 문제에만 포커스를 맞추어서는 안 됩니다. 좋은 개발자는 정말 좋은 프로그램을 개발하기 위해 도움이 될 수 있는 모든 것을 고려하는 자세를 가지고 있어야 합니다.  Agile 소프트웨어 개발 방법론은 개발자들에게 좀 더 다방면으로 능력을 발휘하기를 요구합니다. 또한 질 좋은 코딩을 할 수 있는 능력을 갖추어야 하고 무엇을 할 것인지 에 대해 개발자는 확실히 파악하고 있어야 하고 해야 할 일이 그렇게 가치가 있지 않으면 해당 requirement에 의견을 제시할 수 있어야 합니다. 간단한 디자인으로 정말 유용한 코딩을 해야 하는 거죠. Story 를 근거로 한 TDD 는 이것을 가능하도록 도와 줍니다.

Testing team more effective

개발자에 의해 만들어지고 automated 된 functional test 들로 tester들은 좀 더 효율적으로 작업을 할 수 있습니다. Tester들은 대부분의 시간을 testing에 사용합니다. performance testing, exploratory testing 그리고 manual testing 등등이 있죠. 그들은 automated test들에 의해 진행될 수 없는 그런 테스트들에 그들의 에너지를 집중할 수 있습니다. 그들은 acceptance criteria 에 좀 더 시간을 투자할 수 있고 실제 작성한 테스트 코드가 아닌 그들의 testing idea 들을 제공할 수 있습니다.

실제 현장에서 일어나는 문제 중 하나는 어떤 tester들은 훌륭한 test code를 코딩하지 못한다는 겁니다. 이 문제는 사용하는 툴이 프로그래밍을 요할 경우 문제가 되죠. 그리고 프로젝트가 점점 커질 수록 test suite들도 점점 거대해 지게 되죠. 이런 문제는 개발자들인 좀 더 많은 functional test들을 작성하면 사라질 수 있습니다.

Agile planning에서는 한개의 story 에 얼마나 많은 작업이 필요한가에 대해 계산해야 합니다. 개발자들이 functional test를 먼저 작성하게 되면 좀 더 자신감을 가질 수 있고 해당 story 가 얼마나 시간이 걸릴지 좀 더 수월하고 정확하게 계산할 수 있습니다. 그렇게 함으로서 좀 더 쉽게 계획을 작성할 수 있게 되겠죠.

TDD 스타일에 대해 여러 장점들을 얘기 했는데요. 가끔 이러한 방식이 아주 어렵다는 것을 알고 있어야 합니다. 이런 방법을 여러번 경험해봤던 사람들에게는 아주 자연스럽고 쉽게 할 수 있는 일들도 그렇지 않은 사람들에게는 처음 받아들이기에 좀 어려울 수 있습니다. 대부분의 사람들에게 TDD 는 mind shift 를 요구 합니다. 대개 개발자들은 코딩을 먼저 하고 테스트하고 문제점들을 수정하는 순서대로 개발을 해 왔을 겁니다. 이들에게 드는 의문은 어떻게 코드 없이 테스트 부터 할 수 있을까 입니다. TDD를 적용하고 실제 그에 따르려면 이 의문점부터 먼저 해결 해야 합니다. 그래야 requirement들을 반영할 test를 작성할 수 있습니다. 처음에 이 작업은 쉽지 않습니다. 하지만 이는 처음 단계에 충분히 시간을 투자해서 익힐 가치가 있습니다. 우리 스스로 배우는 자세로 가치를 우선으로 두는 소프트웨어 개발을 생각해야 합니다. 유경험자와 같이 일을 할 수 있으면 이 방법론에 좀 더 빨리 잘 접근할 수 있겠죠.

Story 에서 TDD를 진행하는 방법은 몇가지 전제조건들이 충족 되어야 합니다.
첫째로 좋은 story 가 준비 되야 합니다. 좋은 story는 독립적이고 가치가 있고 예측할 수 있고 작고 테스트가 가능한 스토리여야 합니다.
좋은 스토리가 있으면 개발자들은 business value를 훨씬 쉽게 이해할 수 있고 좋은 question들을 제기할 수 있습니다.
그리고 작고 테스트가 가능해야 하는데요. 그래야 적정 시간 안에 writing test first 를 하면서 일을 끝낼 수 있습니다.

두번째로는 각 스토리에 대한 acceptance criteria 들이 분명해야 합니다. 그래야 개발자들이 그것을 근거로 쉽게 test들을 개발할 수 있습니다.
좋은 스토리는 성공적인 프로젝트의 corner stone 입니다.

Difficult in some areas like cpp, game, restricted by the availability of tool set

이 접근법에 대해 얘기 한 것 중 중요한 한가지는 좋은 functional testing tool을 갖는 겁니다. 실제 프로젝트에서 가끔 여러분의 어플리케이션에 맞는 좋은 functional testing tool을 찾는 것은 아주 어려울 수 있습니다. 여러분이 사용하는 프로그래밍 언어와 어플리케이션이 돌아갈 플랫폼 혹은 프레임워크에 따라 좀 더 어려워 질 수도 있습니다. 예를 들어 Windows desktop 어플리케이션을 위한 딱 맞는 툴을 찾기는 어렵습니다. QTP는 놓은 툴인데요 TDD에는 좀 무거운 감이 있습니다. 다른 예로는 게임이 있습니다. C나 Cpp를 사용하는 게임 프로젝트에는 TDD를 적용하기가 어렵습니다.

툴들도 진화합니다. 몇년전에는 웹 어플리케이션을 위한 툴을 찾기도 아주 어려웠습니다. 하지만 요즘은 웹 어플리케이션 functional testing을 위한 툴들은 아주 많습니다. 필요하게 되면 사람들은 좀 더 좋은 툴을 만들게 될 겁니다.

Build will get slow if not being careful because functional tests number increases

신경쓰지 않으면 Build 는 slow하게 될 겁니다. 왜냐하면 functional test들의 숫자가 증가하게 될 테니까요.

정의 하자면 functional test는 소프트웨어의 실제 functionality를 테스트 하는 겁니다. functional test에서는 대개 database들에 접근하고 네트워크를 통해서 데이터를 전달하고 파일을 읽고 쓰는 일 등등을 하게 됩니다. 일반적으로 발생하는 문제점 중 하나는 프로젝트가 점 점 커가게 되면 이런 모든 functional test들을 running 하는데 걸리는 시간이 훨씬 더 길어지게 된다는 겁니다. 이렇게 되면 functional test로부터 feedback을 빨리 받을 수 없게 되죠. 그리고 팀의 생산성도 떨어뜨립니다. 그러면 개발자들이 의도하지 않는 테스트들을 돌리고 의도하지 않는 functional test들을 작성하도록 만듭니다.

가끔 실제로 프로젝트를 진행하다가 그런 상황을 맞게 되는데요. 대부분 그 문제를 해결하기 위한 여러 해결방법들을 찾을 수 있습니다. 혹은 그냥 skip 할 수도 있죠.
예를 들어 개발 중에 functional test들을 작성하고 실행시킬 때 check in 하기 전에 모든 테스트들을 미리 run 해 볼 수 있습니다. 필요하면 테스트들을 좀 더 작은 group으로 나눠서 그 그룹들을 parallel 하게 돌릴 수도 있죠. 또한 우리의 테스트들을 reorganize할 수도 있고 stub과 mock을 사용해서 실제 외부 시스템에 접근하지 않고 테스트를 하도록 할 수도 있습니다.

TDD 프로젝트에 참여하면서 정말 많은 것들을 배우고 있습니다.

새로운 프로젝트에 익숙해 지느라 블로그 포스팅을 오랫동안 못 하고 있는데요.

배우는 것들을 다 정리를 해 두지는 못하더라도 가능한대로 그때 그때 블로그에 정리를 해서 한번 배울때 더 확실히 이해하고 다음번에 같은 일을 할 때 좀 더 편하고 깊게 작업을 해서 점점 더 훌룡한 프로의 모습을 갖춰가고 싶네요.

또 그 글을 이렇게 공개된 블로그에 정리해 두면 다른 분들에게도 도움이 될 수 있을 것 같구요.

일단 개념 정리부터 하겠습니다.

써핑하다가 좋은 글을 발견해서 그 글 부터 정리해 둘 까 합니다.

http://exceedhl.thoughtworkers.org/Programming/2007/08/02/tdd-a-top-down-style.html

영어 되시는 분은 위 링크 가서 직접 보시면 좋을 거예요.

2007년도에 작성한 글이네요.

한번에 다 정리하지는 못하고 여러번에 나눠서 정리해야 될 것 같네요.

TDD from starting from user stories - a top-down style

새로운 프로젝트에 투입되면서 모바일 쪽이랑은 완전히 멀어졌어요. T_T

지금은 은행쪽 프로젝트를 하고 있습니다.

한달동안 무지 헤맸는데 이제 조금씩 자리가 잡혀가고 있는거 같아요.

저는 Testing team 에 속해 있습니다.

현재 프로젝트에 TDD (Test Driven Development) 개념을 도입시키려고 하는데... 실제 일 시키는거 보면 그것 보다는 일단 JUnit 으로 TestCase 들 만드는게 주 일 입니다.

한달동안 일하면서 들었던 여러 용어들을 일단 적어 놓으려구요.

아마 이번 프로젝트 하는 기간에는 이 용어들과 관련된 기술에 대한 글들을 위주로 블로깅을 할 것 같네요.

- 프레임워크는 기존 Struts 프레임워크를 사용하는 애플리케이션들이 있고 새로 만드는 애플리케이션들은 Spring을 사용할 것임

- LLD (Low Level Degien) 문서를 근거로 JUnit 으로 TestCase를 만듬

  그런데 지금까지는 TDD 개념을 프로젝트에 적용하지 않아서 이 부분이 미진함.

- JUnit, JWebUnit, Soup UI 등의 테스팅 툴들을 사용할 것임

- 애플리케이션 단에서 Web Service 와 연계된 메소드들을 테스트 하기 위해서는 Mockito, inject 를 사용함

- Web Service 테스트는 Soup UI 로 함

- JWebUnit 은 UI 단 테스트의 Automation 을 위해 사용함

- 그 외 Functional Testing, Acceptance Testing 등을 진행 함

- Mobile을 위한 어플리케이션도 있는데 이 부분은 Struts를 사용함

- IDE 는 JBoss Studio 4.0 을 사용함 (Eclips 와 거의 같음)

- Maven 으로 Dependancy 관리 함

- MKS Integrity 에서 소스파일 관리를 함

- JDK 1.6 을 사용함

- Oracle 11G를 사용함

일단 기억나는 것들은 이런 것들 입니다.

앞으로 이 프로젝트가 끝날 때까지 이와 관련된 기술들을 깊이 공부할 생각입니다.

프로젝트가 은행 온라인 뱅킹 관련 프로젝트인데요.

이곳 온라인 뱅킹은 한국의 은행 온라인 뱅킹이랑 조금 다른점이 있는거 같아요.

새로운 분야를 공부할 좋은 기회입니다.

프로젝트 기간이 6개월이니까 최소한 그 기간동안은 이쪽에서 사용되는 기술이나 개념을 익히는게 우선이겠네요.

물론 관심이 있는 모바일 쪽도 계속 공부는 할거지만요.

여기 캘리포니아 쪽에서 모바일 인력 필요하신 분들은 연락 주세요....

뭐든지 배우려면 실무를 하면서 배우는것이 더 효율적이잖아요.

다음 프로젝트는 모바일쪽을 하고 싶네요....

여기도 모바일쪽과 연관된 분야가 있으니 그쪽 일을 좀 더 많이 맡아야겠어요.

지난달에는 거의 글을 못 올렸는데요.

아마 당분간 여기 일이 익숙해 질 때까지는 글 올리는 일이 힘들 것 같습니다.

일이 익숙해 지면 계속 공부하면서 글 올리겠습니다.

사람
 

사람을 법으로 탐구하되

경쟁의 도구로 삼지마라.

법을 탐구하면 진실을 얻지만

사람에게 도전하면 이기심이 커진다.

수행자가 주목해야 할 대상은

법이지 사람이 아니다.

사람을 법으로 보면 단지 알아차릴 대상이라서

마음을 오염시키지 않는다.

사람을 경쟁상대로 보면 알아차리지 못해

마음을 오염시킨다.

법은 완전한 것이라서 탐구할 가치가 있지만

사람은 허약한 존재라서 도전할 가치가 없다.

사람은 있지만

단지 부르기 위한 명칭이므로 실체가 없다.

사람을 경쟁상대로 생각하면

스스로 눈을 가리어 드러나 있는 진실을 보지 못한다.

수행자는 궁극의 가치를 위해서 노력하고

자신의 이기심을 위해서 노력하지 말아야 한다.
  
  상좌불교 한국 명상원
http://cafe.daum.net/vipassanacenter 

Hi guys

I'd like to introduce an Animation Detailed Historycal Background about Military Sexual Slavary during the Sino-Japanese War and the Pacific war.

You can see historycal background at here.

Directed by Kim Junki
Voice by Jeong Seowoon (1924~2004)

This is a story of real person, Jeong Seowoon(정서운), who was forced to work as military sexual slave(comport woman) by Japanese army during the Sino-Japanese War and the Pacific war.

It is the Youtube link.

http://youtu.be/c9ihg1g8ZjU

얼마전 한국 격투가 선수가 욱일 승천기가 그려진 도복을 입고 출전한 서양 격투기 선수에게 이 욱일숭천기가 일본 제국주의의 상징으로 나치와 비슷한 의미라고 메일을 보냈다죠?

그러자 그 선수가 몰랐다면서 미안하다고 답장을 보내고 그 도복을 만들었던 일본 회사도 다시는 욱일승천기로 제품을 만들지 않겠다고 공개적으로 약속했다는 소식을 들었습니다.

저도 주위에 외국인 친구들이 여럿 있는데 이렇게 글을 올리면 facebook이랑 twitter에 같이 올라가니까 그 친구들이 볼 수 있을 것 같아 이렇게 애니메이션을 올립니다.

사람들이 잘 몰라서 이런 일본 제국주의의 상징을 버젓이 공공장소에서 사용하는 일이 없도록 많이 알리고 싶네요.

그리고 한국인으로서 이런 일본 제국주의를 숭상하고 일제시대 일본왕에게 충성을 맹세하는 혈서를 쓰고 독립운동을 토벌하는 군부대 장교였던 박정희.

해방 후에도 무력을 동원해 대한민국의 정권을 빼앗고 국민들의 자유를 인권을 유린하는데 앞장선 독재자 박정희.

해방후에도 일본에 가서 기시 노부스케에게 자신은 이토오 히로부미 같이 메이지 유신을 일으킨 일제 군국주의의 뇌수들을 존경한다고 일본어로 얘기했던 완전 골수 친일파 박정희놈.

그런 쓰레기 같은 놈을 아직도 숭상하는 한국 사람들도 정신 차리고 제대로 역사를 알았으면 좋겠습니다.

아래 발뉴스 링크를 열어 보시면 그 정찬성 격투기 선수가 메일을 보냈던 일화에 대한 인터뷰를 보실 수 있습니다.

http://youtu.be/rbJEaIZKLZE

샌디에고로 이사왔습니다.

반년짜리 프로젝트인데... 이곳에서 열심히해서 인정받고 다름 프로젝트에도 채택되고 해서 좀 오래 있었으면 좋겠네요.

그렇지 않으면 반년 후에 어떻게 될지 모르는게 취업비자로 이곳 미국에서 일해 먹고 사는 처지네요..

지난번 로드 아일랜드 쪽 프로젝트도 끝나고 다음 프로젝트 찾으면서 비자 transfer도 생각하고 하느라고 여간 스트레스가 아니더라구요.

이번에는 은행 Bill Payment 프로젝트인데 TDD 를 사용하는 프로젝트 입니다.

저는 테스팅 팀에 소속돼 있는데 팀원들이 다 개발자 출신이고 테스팅 업무 경험이 없어서 배우면서 해야 되네요.

당분간은 다른 공부 할 시간이 없을 것 같습니다.

가끔 TDD 쪽 공부하다가 여유 되면 여기 블로그에 올릴 생각입니다.

LA 밑에 있는 San Diego 로 이사왔는데 완전 외국 분위기 나고 정말 좋네요.

미국 동부랑은 완전 세상이 다릅니다.

이곳에서는 인터넷을 달지 않을 생각입니다.

아파트 관리사무실 건물에 WiFi 사용할 수 있는 곳이 있거든요. 쓸 일 있으면 관리사무실 건물로 가서 사용하려구요.

집에서 인터넷 하면서 헛시간 소비하는 일이 줄어들겠네요.

그동안 한국 소식을 접하지 못했는데..

박근혜는 아직도 사람들을 다 인선을 못했네요. 인사 능력이 영 엉망인것 같고... 약속을 지킨다는 이미지를 그렇게 심어주고 강조했는데... 공약들도 다 어긴다고 하고...

그냥 MB 한테도 그랬듯이 5년동안 별일 안하고 조용히 있다가 떠나주기를 바랍니다.

MB는 그동안 쌓아왔던 민주적인 틀을 무참히 짓밟고 나갔죠.
거기에는 그런 권력에 빌붙어서 놀아났던 놈들이 있었기 때문에 가능했던 겁니다.

MB도 깜방에 보내야겠지만 김재철 같은놈 그리고 국정원 불법선거, 정치검찰의 한심한 작태들을 상기하면 MB에 부역했던 놈들도 다 처벌해야 된다고 생각합니다. 반드시......

참여연대에서 MB 정부의 정치검사 46명의 명단을 공개했네요.

http://www.gobalnews.com/news/articleView.html?idxno=379 로 가시면 관련 기사를 보실 수 있습니다.

이 정치 검사놈들 꼭 기억하고 진실을 밝혀내고 반드시 처벌해야 합니다.

San Diego 에서 진행되는 새로운 프로젝트에 참여하게 됐습니다.

지난번 진행하던 New England 프로젝트는 중국 팀이 생기면서 그쪽 팀으로 업무가 모두 이관 되면서 제 역할은 끝났구요.

인도에 이어 이제 중국이 IT 쪽도 잠식해 들어가기 시작하는 건가?

몇달간 Knowledge Transfer 를 진행하고 일도 같이 진행하고 했는데... Dalian에 있는 중국애들이랑 같이요...

적극적이고 feedback 빠르고 확실하고 실력도 좋고 괜찮더라구요.

무엇보다도 영어가 그렇게 유창하지 않은데 부끄러워하거나 주저하지 않고 적극적으로 자신의 의견을 내고 항상 회의에 적극적으로 참여하는 게 인상 깊었습니다.

몇달간 중국팀으로부터 저도 많은 것을 배웠어요.

인도애들이 긴장해야 되겠던데요... 중국애들이 치고 들어오면 미국내 IT 를 잠식하고 있는 인도의 위상이 약간 변화가 오지 않을까.....

제가 이렇게 남 걱정 하고 있을 때가 아니죠.

언제든지 선택받지 못하면 한국으로 돌아가야만 되는 미국에서의 외국인 노동자로서 New England 쪽 프로젝트 끝나가면서 접했던 그 한 없는 불안감과 막막함 그리고 초라함이 다시는 반복되지 않도록 좀 안정 됐으면 좋겠네요.

San Diego 로 오면서 봤던 저 삭막한 사막처럼 외국인 노동자로 산다는 건 정말 건조한거 같아요.

오늘부터 새로 시작하는 San Diego 프로젝트.....

열심히 해서 더 인정받고 더 안정된 미국에서의 외국인 개발자가 되고 싶어요.... ;;

수요일 입니다. 다시 FAQ 시간이 돌아왔습니다. 오늘의 주제는 런타임 에러 처리와 안드로이드 퍼미션에 관한 내용들을 다루겠습니다.

1. What about the Runtime Error Message Popup on current Daily Builds?

안드로이드용은 Build 1030부터 그리고 다른 플랫폼들은 Build 1047 부터 적용됐는데요. 런타임 에러가 나면 팝업 메세지 박스가 뜨고 파일과 line number 와 함께 해당 에러를 보여 줍니다. (debug build 로 세팅 됐을 경우에요).  그리고 물론 콘솔에도 에러 정보가 뜨구요. 그러니까 이제는 콘솔 없이도 런타임 에러를 볼 수 있는 기능이 추가 된거죠. Build 1047 부터 여러분 코드에 런타임 리스너를 include 하실 수 있습니다. 이 리스너는 에러를 trap 하고 런타임 팝업 메세지 박스를 뜨지 않도록 할 수 있습니다. 이 때 다른 동작을 행하도록 분기해 버리면 런타임 에러가 발생해도 앱이 멈추지않고 계속 작동하게 할 수 있습니다.

모든 플랫폼과 맥/윈도우 시뮬레이터에서 런타임 메세지 박스는 디폴트로 보이도록 설정돼 있습니다.

2. How do I implement a Lua Runtime Error Listener?

아래 예제를 보시면 런타임 리스너를 어떻게 implement 하는지 보실 수 있습니다. ("unhandledError") 코로나 시뮬레이터나 디바이스에서 이 코드를 실행하면 print statement 의 string 과 함께 concatenating a nil value 에 의해 발생한 에러를 보실 수 있을 겁니다.

local releaseBuild = true   -- Set to true to suppress popup message

-- Error handler
local function myUnhandledErrorListener( event )

    if releaseBuild then
        print( "Handling the unhandled error >>>\n", event.errorMessage )
        display.newText( ">>> ERROR OCCURRED <<<", 30, 1, native.systemFont, 18 )
    else
        print( "Not handling the unhandled error >>>\n", event.errorMessage )
    end
    
    return releaseBuild
end

Runtime:addEventListener("unhandledError", myUnhandledErrorListener)

-- Displays text message in center of screen
txtMsg1 = display.newText( "Runtime Error Test Code", 55, 200, "Verdana-Bold", 14 )

print( "ABC" .. nil )  -- <<<< Lua error here

이 리스너에서 false (default value)가 return 되면 이 리스너 함수를 나갈 때 팝업 메세지 박스가 뜹니다. true 가 return 되면 리스너 함수가 런타임 에러를 처리한다는 의미 입니다. 그래서 팝업 메세지가 뜨지 않습니다. 위 코드에서 releaseBuild 변수는 팝업 메세지가 표시 될지 안될지를 결정하는 변수 입니다.

3. What is the best practices for the Runtime Error Listener?

런타임 팝업 메세지 와 런타임 에러 리스너 기능을 추가한 이유는 진행되는 코드의 상황과 에러를 보여줄 수 있는 툴을 개발자들에게 제공하기 위해서 입니다. 만약에 디버그를 위해서 빌드를 한다면 (iOS에서는 developer mode가 되겠고 안드로이드에서는 debug key 를 사용한 빌드가 되겠죠.) 에러가 발생한 파일과 그 line number 가 포함된 런터임 에러 정보를 보실 수 있을 겁니다. 이 정보들은 팝업 메세지 박스를 통해서 보게 되죠. 만약에 런타임 리스너를 추가하고 이 팝업 박스를 띄우지 않는다고 하더라도 그 에러 정보들을 얻을 수 있습니다. (리스너에 전달된 event table 이나 콘솔창등에서요.)

production release 라면 error type 만 가능합니다. 런타임 리스너를 implement 하시고 에러 팝업을 띄우지 않도록 세팅한 다음 내부적으로 그 에러를 log 하게 되죠. 이 에러 로그로 무엇을 할 지는 여러분이 하기 나름입니다. 그냥 무시할 수도 있고 문제점들을 track 하기 위해 서버로 보낼 로그 파일을 만들수도 있구요. 팝업 에러가 뜨도록 하는 것의 장점은 이 에러 정보가 Google Play 에 전달 될거라는 겁니다. 개발자들은 그 에러 정보를 Google Play 에서 보실 수 있게 되는 거죠. 만약 팝업 창을 띄우지 않게 되면 여러분이 에러 정보를 log 해서 여러분의 서버에 전달하지 않는한 그 에러 정보는 lost 되게 되죠.

디버그 할 때는 대부분 런타임 팝업이 뜨도록 하는 경우가 많을 겁니다. 그리고 앱 스토어에 올릴 때는 그 팝업을 띄우지 않도록 바꾸는 경우가 많을 거구요.


이전 FAQ 에서 언급한 건데요. 에러를 그냥 무시해 버리는 것은 그다지 좋은 방법은 아닙니다. 런타임 에러가 발생하면 앱이 안정적이지 않게 될 수 있습니다. 가능하면 많은 디바이스에서 앱을 테스트 해 보고 에러가 발생하면 이 에러를 없애거나 pcall 을 이용해서 trap 하셔야 합니다.

4. I'm using the Runtime Listener but I'm still getting the Runtime Error popup.

여러분 코드에서 런타임 에러 리스너를 implement 해서 에러 팝업창을 띄우지 않도록 했는데도 계속 팝업이 뜬다면 런타임 리스너가 시작하기 전에 런타임 에러가 일어났을 가능성이 큽니다. 위 예제에서 보여드렸듯이 런타임 리스너 함수는 코드 내에서 정의를 하셔야 합니다. 그리고 그 함수를 가능하면 빨리 enabling 하셔야 합니다. 그래야 에러를 trap 하실 수 있습니다. 런타임 에러 리스너가 enable 되기 전에 일어난 에러들은 당연히 팝업 메세지를 발생시킬겁니다. 일반적으로 startup 시 발생하는 에러는 fix 하기가 쉽습니다. 그리고 trap 작업도 필요 없구요. 터치 이벤트, 충돌 등이 일어날 때 발생하는 런타임 에러들이 trap 해야할 그런 에러들 입니다.

5. What about Android Permissions and runtime errors?

Build 1030에서 안드로이드 Manifest 에서 디폴트 퍼미션을 없앴습니다. 여러분이 필요한 퍼미션들을 추가해야 된다는 얘기죠. Daily Build 샘플 코드 프로젝트와 API 페이지들을 보시면 build.settings 파일 안에 필요한 퍼미션들이 있읍니다.

대개 퍼미션을 빠뜨리면 런타임 팝업과 함께 런타임 에러가 발생합니다. (혹은 unHandledError 리스너가 call 되기도 하죠.) 퍼미션을 빠뜨리는 것은 앱을 릴리즈 하기 전에 뭔가가 테스트 되고 또 fix 되어야 한다는 얘기 입니다. (6번 질문을 보세요.)

6. Which Android Permissions won't generate a runtime error?

어떤 API call 들은 build.settings 파일에 특정 퍼미션이 세팅되어 있지 않으면 조용히 fail 해 버립니다.
아래와 같은 것들인데요.

• display.capture
• display.captureBoard
• display.captureScreen
• media.newRecording
• media.newVideo
• media.save
• media.show
• native.webView
• native.newWebPopup
• heading( Compass) event
• location (GPS) event

위의 API들을 사용할 때는 그 코드가 원하는대로 제대로 작동하는지 꼭 확인하셔야 됩니다. build.settings 파일에 이런 퍼미션들이 세팅되어 있는지도 한번 더 확인하는 습관도 좋은 거 같습니다.


각 API 별로 필요한 안드로이드 퍼미션이 무엇인지 보시려면 Daily Build Documents 를 확인해 보세요.

That's it for today's answers. I hope you enjoyed them and even learned a few things!

9. Pre-create Physics Bodies

만약 여러분 시나리오에서 여러 physics body 들을 사용하려고 한다면 그 physics body 들을 non-time-critical code 에서 미리 생성해 두는 것이 좋습니다. 어딘가 스크린 밖에 inactive 상태로 두던가 invisible display group 으로 두었다가 필요하면 active 상태로 바꾸면 되거든요.

그냥 physics body 들 몇개를 time-critical code 내에서 생성하는게 그다지 큰 문제가 되지는 않습니다 단지 한 game 사이클에서 10~20 개의 physics body 들을 한꺼번에 생성하는 것을 피하기 위해서입니다. 이렇게 한꺼번에 생성하면 인식할 수 있을 정도로 frame rate 이 skip 이 일어날 겁니다.

그리고 이 방법은 어떤 면에서는 balancing act 라고 얘기할 수도 있습니다. 200개의 physics body 들을 사전에 생성해서 deactivate 시키게 되면 Box2D 세계에서 이것들을 remove하게 됩니다. 하지만 Corona의 메모리에서 remove되는 것은 아닙니다. 그래서 이렇게 극단적으로 많이 사용할 경우에는 그렇게 효과가 크지 않을 수도 있습니다.

10. Utilize Audio “Best Practices”

앱에서 사용하는 음향효과는 항상 non-time-critical code 에서 pre-load 되어야 합니다. 예를 들어 scene 이나 level 이 시작(begins) 되기 전에 말이죠. 또한 이러한 사운드들을 사용 가능한한 범위 내에서 용량을 최대한 줄여야 합니다. 11khz mono (not stereo)는 대부분의 경우에 acceptable 합니다. 유저가 폰이나 태블릿 스피커 혹은 여러 이어폰을 통해서 들을 수 있는 범위에 속하죠. 그리고 간단하게 그리고  WAV 같은 cross-platform 포맷을 사용하세요. 그래서 CPU를 너무 무리하게 일을 시키지 마세요.

그리고 음향효과들은 아래처럼 테이블로 관리하기를 권장합니다. 쉽게 참조할 수 있고 더 이상 필요 없으면 쉽게 처분할 수 있도록 말이죠.

--load these sounds during NON-time-critical code
local soundTable = {
   mySound1 = audio.loadSound( "a.wav" ),
   mySound2 = audio.loadSound( "b.wav" ),
   mySound3 = audio.loadSound( "c.wav" ),
   mySound4 = audio.loadSound( "d.wav" ),
   mySound5 = audio.loadSound( "e.wav" ),
   mySound6 = audio.loadSound( "f.wav" ),
   mySound7 = audio.loadSound( "g.wav" ),
   mySound8 = audio.loadSound( "h.wav" ),
}

위와 같은 구조라면은 playback 은 다음과 같이 간단하게 사용하실 수 있습니다.

local mySound = audio.play( soundTable["mySound1"] )

항상 그렇듯이 특정 음향효과가 더이상 필요하지 않다면 깨끗하게 정리하는 걸 잊지 마세요. 그리고 이 테이블에서도 reference를 깨끗하게 처리하세요.

local ST = soundTable
for s,v in pairs(ST) do
   audio.dispose( ST[s] ) ; ST[s] = nil
end

여기까지가 퍼포먼스 최적화와 관련된 내용입니다. 개발자로서 이 퍼포먼스 최적화(performance optimization) 은 끝없이 꾸준히 해야 될 일입니다. 그리고 항상 best practice를 해야 합니다. 아무쪼록 이 글에서 다룬 몇가지 팁들이 여러분 앱의 퍼포먼스를 boosting 시키는데 조금이라도 도움이 됐으면 합니다. 질문이나 댓글은 언제든지 환영합니다.

이로써 퍼포먼스 최적화 관련 글을 4번에 걸쳐 다 한글로 옮겨 놨습니다.

항상 코딩하면서 적용해보고 적용해보고 이렇게 반복 연습해서 몸에 익혀 둬야할 내용들 같습니다.