IT/모바일
Cooking with Ruby on Rails - Designing for Testability (1)
제공 : 한빛 네트워크
저자 : Bill Walton
역자 : 노재현
원문 : Cookin" with Ruby on Rails - Designing for Testability
점심을 다 먹은 CB는 갑자기 이런 생각이 들었다. "피자도 맛있게 먹었으니 이제 시간안에 Rails로 하기로 했던 일을 끝내면 좋겠는데...". 이런 생각이 들자마자 역시나 다를까 Paul이 계속해서 하던 일을 하기위해 문을 두드리는 소리를 들을 수 있었다.
Paul : 안녕하세요. 하던 일을 계속 해볼까요?
CB : 응 마침 잘 왔어. 테스터로서의 역할을 할 준비는 다 된거야?
Paul : 네, 물론이죠. 테스터를 해보면 Rails에 익숙해지는데 더 많이 도움이 될 것 같아요. 그런데 궁금한게 있는데요 전에 제가 우리 보스하고 더 자주 만날 수 있기 때문에 테스터 역할을 하기에 적당하다고 했었잖아요? 저는 그 뜻을 잘 모르겠어요. 조금 더 설명해 주실 수 있을까요?
CB : 음 솔직하게 말해서 사실은 다방면으로 테스팅을 하는데 있어서 Paul이 보스를 설득해 주기를 바래서 그랬던 거야. 몇년 전에 했던 프로젝트에서는 개발, 생산, 보장 수리와 같은 다양한 부분에 초점을 맞춰서 개발을 했었는데, 이런 개발 프로세스를 테스트 가능한 디자인이라고 불렀었지. 그 프로세스에 대한 전제는 디자인 자체가 테스트할 수 있는 여지가 많을 수록 만들어서 생산하는데 들어가는 비용이 줄어들고 더 빨리 시장에 제품을 내 놓을 수 있다는 거였거든. 그리고 그때 그 생각은 효과가 있다는 것으로 판명이 났지. 난 이 방법이 소프트웨어에서도 마찬가지일 거라고 생각하고 있어. 그래서 Paul 자네가 보스를 설득하는데 도움을 줬으면 좋겠다고 생각하고 있었고. 원하는 건 개발을 시작하기 전에 고객 허용 테스트 내용을 받았으면 하는거야. Paul 자네가 평상시에 보스와 자주 만날 수 있으니 보스에게 고객 허용 테스트를 작성해 달라고 했으면 한다구.
Paul : 네. CB씨가 말씀하신 내용을 완벽하게 이해했는지는 잘 모르겠네요. 하지만 제가 여태까지 작업해왔던 걸 생각해보면 참 끔찍해요. 제가 여태까지 해왔던 프로젝트는 항상 동일한 방식으로 진행을 해왔어요. 개발을 시작해서 테스팅 단계까지는 아주 순조로웠죠. 그리고 테스팅을 거쳐서 고객의 손에 들어가기 시작하면 악몽이 시작되요. 고객이 프로그램에 버그가 있다는 연락을 해오기 시작하고 개발자는 요구서에 있는 대로 작동하게 해놨다고 하죠. 그리고 나서 보스와 그 상사님들과 회의를 가지고 왜 스케쥴 대로 프로젝트가 진행되지 못했는지 등등에 대해서 얘기를 하게 되요. 그런데 이번 프로젝트에서 제가 테스터의 역할을 하게 된다니, 뭔가 배울게 많을 것 같은데요. 한 번 해봐요.
CB : 좋아 그럼 시작해 보자고. 먼저 웹 서버를 띄우고 전에 만들고 있던 애플리케이션이 잘 작동하는지 확인해 보자.
Paul : 넵. 먼저 Mongrel 을 시작하고
[그림 1]
우리 애플리케이션을 브라우저에서 열어보면
[그림 2]
Paul : 잘 나오네요. 나머지 부분도 잘 되는지 좀 더 확인해 볼까요?
CB : 어떻게 작동하고 있었는지 다 기억하고 있어?
Paul : 음 아직 애플리케이션이 간단하기도 하고 지난 번 마지막으로 작업한지 오래되지도 않아서 잘 알고 있어요. 하지만 지금하신 질문의 의도를 알 것 같아요. 이렇게 잘 작동한다고 판단하는 방법이 가끔씩 테스팅을 하는데 있어서 문제가 되었었어요. 예를 들어 한 동안 애플리케이션을 테스트하지 않던 고객이 와서 이렇게 말 할때가 있었어요. "이거 이렇게 작동하지 않았었는데 버그가 생겼네요?" 그럼 개발자는 이렇게 대답하죠. "아니예요 전에도 그렇게 작동했었어요". 그리고 나서 혹시 뭔가가 잘못 되었을 수도 있을지 모르니 테스트 계획을 쭉 살펴봐요.
CB : 그래서 테스팅 계획은 어땠어?
Paul : 우선 계획 자체를 만드는데 굉장히 많은 시간이 필요했어요. 고객한테 직접 자세한 계획서를 작성해 달라고 하는 것도 거의 불가능했죠. 그래서 계약직으로 몇 명 고용할 수 밖에 없었고요. 하지만 그것도 문제중에 하나였죠. 고객들이 보스에게 전문적으로 테스트 계획을 세우고 고객들을 대신해서 테스트를 할 수 있는 부서를 만들라고 요청을 하기 시작했어요. 하지만 보스에게 테스트만을 위해서 단순히 머리 숫자를 늘리는 것은 먹혀들리가 없었죠.
CB : 그래. 테스트 계획을 작성하고 멍하니 앉아서 테스트를 수행하면서 시간만 보내는 건 별로 좋은 생각이 아니지. 시간 얘기가 나와서 말인데 우리가 만들었던 애플리케이션이 정상적으로 작동하는지 테스트 해보는데 얼마나 걸릴 것 같아?
Paul : 몇 분 안 걸릴것 같은데요. 제가 평상시에 하고 있던 프로젝트와 비교하면요. 지금 제가 하고 있던 프로젝트는 한 차례의 테스트를 위해서 6명의 고객이 일주일동안 풀타임으로 테스팅을 해야 하거든요. 거기에 비하면 이건 정말 쉽겠는데요. 한 3, 4분이면 되겠어요.
CB : 좋았어. 그럼 나는 나가서 음료수 좀 사가지고 올테니까 잘 하고 있어.
CB는 나가면서 씩 웃으면서 이런 생각을 했다. "이번 개발이 끝나면 Paul이 혁신적인 사람이 되기 위해서 노력하는 걸 볼 수 있겠는데"
CB : 다 됐어?
Paul : 네. 예전에 작동하던데로 잘 작동하는 것 같은데요. 이제 무엇을 하게 될지 알려주실 수 있으세요? 아마도 자동화된 테스트를 진행하게 될 것 같은데, 딱 거기까지만 알고 나머지는 잘 모르겠어요. Rails에서는 어떻게 하는거죠? 저번에 봤던 테스터 한 명은 GUI로 된 툴로 한다고 하던데. 여기서도 그런가요?
CB : 으...음. 아니야. 오해는 하지 말고. 내말은 그런 툴이 없다는 건 아니야. 내 친구중에 "green screen"이라는 애플리케이션을 개발하는 사람이 한 명 있는데, 그 친구 상급자가 애플리케이션의 자동화 테스트 기능을 넣으라고 했거든. 근데 GUI 테스트를 하는 것 말고는 다른 뾰족한 수가 없었어. 그 친구 입장에서는 선택의 여지가 없었지만 우리 같이 Rails를 사용할때는 선택의 여지가 있어. 초심자를 위해서 Rails에는 테스팅 프레임웍이 포함되어 있어. 테스팅 프레임웍이 Rails에 추가로 설치해야하는 툴이 아니라는 거지. 그리고 Rails에서 사용하고 있는 MVC 패턴에 대한 테스트를 완벽하게 지원해 주고 있어. 아직 여기서 사용하는 용어에 익숙해 지려면 시간이 좀 걸릴 수도 있겠지만. 우리가 만든 Model을 이제 부터 "Unit 테스트"라고 불리는 것을 이용해서 테스트하게 될거야. Rails에서는 Model의 기능을 테스트하는 것을 Unit 테스트라고 부르고 있어. "Funtional 테스트"라고 불리는 건 controller를 테스트 하는 것을 의미하고 "Integration 테스트"는 애플리케이션의 기능을 테스트하는 것을 의미해. 어떤 사람들은 이 용어들을 평상시에 사용하던 용어와 달리 특수한 용어로 생각하는 사람도 있는데, 나는 MVC 모델에 근거한 아주 적합한 용어라고 생각해.
Paul : 그렇군요. 그럼 처음으로 해야되는 건 뭐예요?
CB : 우선 테스트 데이터베이스를 만들어야해.
Paul : 아.. 이미 다 하신 것 같은데요.
CB : 가만 가만. Rails로 얼마나 쉽게 개발을 할 수 있는지 봤잖아? 그리고 테스팅 프레임웍은 이미 Rails에 포함이 되어 있다고 말했고. 그럼 Rails로 어떻게 할 수 있는 한 번 보라고.
이제 테스트에만 사용하게 될 데이터베이스를 만들게 될거야. 이제부터 사용하게 될 테스트 데이터베이스는 테스트를 수행할때 매번 모든 내용을 지우고 테스트를 수행하게 될거야. 그러니까 테스트를 수행할 때는 항상 테스트베이스에서 하게끔 주의를 해야해. 우리가 만들었던 데이터베이스 설정 기억하고 있어? 자 한 번 열어보자.
[그림 3]
CB : 먼저 데이터베이스를 만들어야 해. 예전에 개발버전의 데이터베이스를 만들던 것과 동일한 방법으로 MySQL에서 하면 되지. 먼저 커맨드 창을 열고 MySQL에 root 유저로 로그인을 할거야. 암호는 아직 설정하지 않았으니 입력하지 않아도 괜찮고. 물론 암호를 설정하는게 맞겠지만 아직까지는 이 시스템에 접근할 수 있는 사람도 나밖에 없으니 나중에 해도 괜찮을 거야.
데이터베이스를 만든다.
[그림 4]
CB : 이제 비어있는 테스트 데이터베이스를 만들었어. 여기에 테이블을 만들어 넣어야 하는데, Rails가 이런 작업들을 우리를 대신해서 다 해주기 때문에 정말 편해. rake의 테스크를 이용하게 되면 개발 데이터베이스에 있는 테이블을 테스트 데이터베이스에 만들 수가 있어.
[그림 5]
Paul : 아무것도 하지 않은 것처럼 보이네요?
CB : 응. rake의 테스크가 어떻게 코딩됐느냐에 따라 다르지. 문제가 없으면 보통 아무 메시지도 출력되지 않아. 쉽게 확인할 수 있는 방법은 데이터베이스 GUI 관리자를 하나 실행하고 확인해 보는거지.
자 여기 우리 개발버전 데이터베이스가 있고
[그림 6]
이건 테스트 데이터베이스야
[그림 7]
Paul : 와 좋네요. 데이터도 같이 복사된 거예요?
CB : 아니. 여태까지 우리가 수동으로 하던 테스트에서는 Production 데이터베이스와 비슷한 수준의 데이터를 필요로 했었지. 또 고객은 항상 보던 데이터를 보고 있을때 테스트 하기가 쉽다고 느껴. 하지만 성공적으로 자동화된 테스트를 하려면 다른 방법으로 생성된 데이터가 필요해. 어떤 사람들은 "가공된 테스트 데이터" 라고 부르기도 하지. 우리가 테이스 데이터베이스에 넣을 데이터는 단순히 테스트를 하기 위해 필요한 데이터 그 이상도 아니고 그 이하도 아니야.
Paul : 아. 계약직으로 고용했던 테스터중 한 명이 그 "가공된 테스트 데이터"에 대해서 말한 적이 있어요. 그 때 보스도 옆에 같이 있었는데 그런 말을 들어본 적이 없다고 하셨었죠. 그래서 그녀에게 무엇인지에 대해서 물어봤는데 이전에 했던 프로젝트에서 만들었던 모든 테스트 계획과 모든 데이터들에 대해서 말해줬어요. 고객들이 모두 돌아가고 나서 프로그램이 정상작동하는지 확인하기 위해서 모든 테스트를 다시 실행했고, 현재 테스트 케이스에 더 자세한 테스트를 추가하고, 새로운 테스트 케이스를 또 추가하고 추가하고. 옆에서 듣고 있던 보스는 아무말도 하고 있지 않다가 "흥미롭군. 우리도 생각 좀 해보야 겠는데". 그리고 나서 자리를 뜨셨어요. 두 번 다시는 보스하고 그 얘기를 하고 싶지 않았어요. 무슨 말인지 아시죠?
CB : 응 알 것 같아. 자네가 말한 것과 지금 우리가 하려는 것과의 차이는 한 마디로 말해서 "레거시 시스템" 이라고 할 수 있어. 레거시 시스템으로 일하는 건 정말 힘든일이야. 레거시 시스템의 단점으로 꼽을 만한게 있다면 자동화된 테스트의 부재라고 할 수 있지. 보스하고 자네가 여기에 처음 왔던 때를 기억하고 있어? 그 때 내가 보스에게 했던 말이 "Rails가 정말 좋은 이유는 개발에 있어서 반복성과 점진성을 이용한다"는 거였어. 그리고 좀전에 Rails에 테스트 기능이 포함되어 있다는 것도 기억하고 있지? 자네가 좀 전에 말했던 안 좋은 상황을 피할 수 있는 방법이 있는데 그건 바로 "레거시 시스템의 빌드를 중단"하는 거야.
역자 노재현님은 어렸을 때부터 컴퓨터를 접하게 된 덕에 프로그래밍을 오랫동안 정겹게 하고 있는 프로그래머 입니다. 특히나 게임 및 OS 개발에 관심이 많으며, 심심할 때면 뭔가 새로운 프로그램을 만들어내는 것을 좋아합니다. 다음에서 웹 관련 개발을 한 후에 현재는 www.osguru.net이라는 OS관련 웹사이트를 운영하며 넥슨에서 게임 개발을 하고 있습니다.
* e-mail: wonbear@gmail.com
* homepage: http://www.oguru.net
저자 : Bill Walton
역자 : 노재현
원문 : Cookin" with Ruby on Rails - Designing for Testability
점심을 다 먹은 CB는 갑자기 이런 생각이 들었다. "피자도 맛있게 먹었으니 이제 시간안에 Rails로 하기로 했던 일을 끝내면 좋겠는데...". 이런 생각이 들자마자 역시나 다를까 Paul이 계속해서 하던 일을 하기위해 문을 두드리는 소리를 들을 수 있었다.
Paul : 안녕하세요. 하던 일을 계속 해볼까요?
CB : 응 마침 잘 왔어. 테스터로서의 역할을 할 준비는 다 된거야?
Paul : 네, 물론이죠. 테스터를 해보면 Rails에 익숙해지는데 더 많이 도움이 될 것 같아요. 그런데 궁금한게 있는데요 전에 제가 우리 보스하고 더 자주 만날 수 있기 때문에 테스터 역할을 하기에 적당하다고 했었잖아요? 저는 그 뜻을 잘 모르겠어요. 조금 더 설명해 주실 수 있을까요?
CB : 음 솔직하게 말해서 사실은 다방면으로 테스팅을 하는데 있어서 Paul이 보스를 설득해 주기를 바래서 그랬던 거야. 몇년 전에 했던 프로젝트에서는 개발, 생산, 보장 수리와 같은 다양한 부분에 초점을 맞춰서 개발을 했었는데, 이런 개발 프로세스를 테스트 가능한 디자인이라고 불렀었지. 그 프로세스에 대한 전제는 디자인 자체가 테스트할 수 있는 여지가 많을 수록 만들어서 생산하는데 들어가는 비용이 줄어들고 더 빨리 시장에 제품을 내 놓을 수 있다는 거였거든. 그리고 그때 그 생각은 효과가 있다는 것으로 판명이 났지. 난 이 방법이 소프트웨어에서도 마찬가지일 거라고 생각하고 있어. 그래서 Paul 자네가 보스를 설득하는데 도움을 줬으면 좋겠다고 생각하고 있었고. 원하는 건 개발을 시작하기 전에 고객 허용 테스트 내용을 받았으면 하는거야. Paul 자네가 평상시에 보스와 자주 만날 수 있으니 보스에게 고객 허용 테스트를 작성해 달라고 했으면 한다구.
Paul : 네. CB씨가 말씀하신 내용을 완벽하게 이해했는지는 잘 모르겠네요. 하지만 제가 여태까지 작업해왔던 걸 생각해보면 참 끔찍해요. 제가 여태까지 해왔던 프로젝트는 항상 동일한 방식으로 진행을 해왔어요. 개발을 시작해서 테스팅 단계까지는 아주 순조로웠죠. 그리고 테스팅을 거쳐서 고객의 손에 들어가기 시작하면 악몽이 시작되요. 고객이 프로그램에 버그가 있다는 연락을 해오기 시작하고 개발자는 요구서에 있는 대로 작동하게 해놨다고 하죠. 그리고 나서 보스와 그 상사님들과 회의를 가지고 왜 스케쥴 대로 프로젝트가 진행되지 못했는지 등등에 대해서 얘기를 하게 되요. 그런데 이번 프로젝트에서 제가 테스터의 역할을 하게 된다니, 뭔가 배울게 많을 것 같은데요. 한 번 해봐요.
CB : 좋아 그럼 시작해 보자고. 먼저 웹 서버를 띄우고 전에 만들고 있던 애플리케이션이 잘 작동하는지 확인해 보자.
Paul : 넵. 먼저 Mongrel 을 시작하고
mongrel_rails start
[그림 1]
우리 애플리케이션을 브라우저에서 열어보면
http://localhost:3000/recipe
[그림 2]
Paul : 잘 나오네요. 나머지 부분도 잘 되는지 좀 더 확인해 볼까요?
CB : 어떻게 작동하고 있었는지 다 기억하고 있어?
Paul : 음 아직 애플리케이션이 간단하기도 하고 지난 번 마지막으로 작업한지 오래되지도 않아서 잘 알고 있어요. 하지만 지금하신 질문의 의도를 알 것 같아요. 이렇게 잘 작동한다고 판단하는 방법이 가끔씩 테스팅을 하는데 있어서 문제가 되었었어요. 예를 들어 한 동안 애플리케이션을 테스트하지 않던 고객이 와서 이렇게 말 할때가 있었어요. "이거 이렇게 작동하지 않았었는데 버그가 생겼네요?" 그럼 개발자는 이렇게 대답하죠. "아니예요 전에도 그렇게 작동했었어요". 그리고 나서 혹시 뭔가가 잘못 되었을 수도 있을지 모르니 테스트 계획을 쭉 살펴봐요.
CB : 그래서 테스팅 계획은 어땠어?
Paul : 우선 계획 자체를 만드는데 굉장히 많은 시간이 필요했어요. 고객한테 직접 자세한 계획서를 작성해 달라고 하는 것도 거의 불가능했죠. 그래서 계약직으로 몇 명 고용할 수 밖에 없었고요. 하지만 그것도 문제중에 하나였죠. 고객들이 보스에게 전문적으로 테스트 계획을 세우고 고객들을 대신해서 테스트를 할 수 있는 부서를 만들라고 요청을 하기 시작했어요. 하지만 보스에게 테스트만을 위해서 단순히 머리 숫자를 늘리는 것은 먹혀들리가 없었죠.
CB : 그래. 테스트 계획을 작성하고 멍하니 앉아서 테스트를 수행하면서 시간만 보내는 건 별로 좋은 생각이 아니지. 시간 얘기가 나와서 말인데 우리가 만들었던 애플리케이션이 정상적으로 작동하는지 테스트 해보는데 얼마나 걸릴 것 같아?
Paul : 몇 분 안 걸릴것 같은데요. 제가 평상시에 하고 있던 프로젝트와 비교하면요. 지금 제가 하고 있던 프로젝트는 한 차례의 테스트를 위해서 6명의 고객이 일주일동안 풀타임으로 테스팅을 해야 하거든요. 거기에 비하면 이건 정말 쉽겠는데요. 한 3, 4분이면 되겠어요.
CB : 좋았어. 그럼 나는 나가서 음료수 좀 사가지고 올테니까 잘 하고 있어.
CB는 나가면서 씩 웃으면서 이런 생각을 했다. "이번 개발이 끝나면 Paul이 혁신적인 사람이 되기 위해서 노력하는 걸 볼 수 있겠는데"
CB : 다 됐어?
Paul : 네. 예전에 작동하던데로 잘 작동하는 것 같은데요. 이제 무엇을 하게 될지 알려주실 수 있으세요? 아마도 자동화된 테스트를 진행하게 될 것 같은데, 딱 거기까지만 알고 나머지는 잘 모르겠어요. Rails에서는 어떻게 하는거죠? 저번에 봤던 테스터 한 명은 GUI로 된 툴로 한다고 하던데. 여기서도 그런가요?
CB : 으...음. 아니야. 오해는 하지 말고. 내말은 그런 툴이 없다는 건 아니야. 내 친구중에 "green screen"이라는 애플리케이션을 개발하는 사람이 한 명 있는데, 그 친구 상급자가 애플리케이션의 자동화 테스트 기능을 넣으라고 했거든. 근데 GUI 테스트를 하는 것 말고는 다른 뾰족한 수가 없었어. 그 친구 입장에서는 선택의 여지가 없었지만 우리 같이 Rails를 사용할때는 선택의 여지가 있어. 초심자를 위해서 Rails에는 테스팅 프레임웍이 포함되어 있어. 테스팅 프레임웍이 Rails에 추가로 설치해야하는 툴이 아니라는 거지. 그리고 Rails에서 사용하고 있는 MVC 패턴에 대한 테스트를 완벽하게 지원해 주고 있어. 아직 여기서 사용하는 용어에 익숙해 지려면 시간이 좀 걸릴 수도 있겠지만. 우리가 만든 Model을 이제 부터 "Unit 테스트"라고 불리는 것을 이용해서 테스트하게 될거야. Rails에서는 Model의 기능을 테스트하는 것을 Unit 테스트라고 부르고 있어. "Funtional 테스트"라고 불리는 건 controller를 테스트 하는 것을 의미하고 "Integration 테스트"는 애플리케이션의 기능을 테스트하는 것을 의미해. 어떤 사람들은 이 용어들을 평상시에 사용하던 용어와 달리 특수한 용어로 생각하는 사람도 있는데, 나는 MVC 모델에 근거한 아주 적합한 용어라고 생각해.
Paul : 그렇군요. 그럼 처음으로 해야되는 건 뭐예요?
CB : 우선 테스트 데이터베이스를 만들어야해.
Paul : 아.. 이미 다 하신 것 같은데요.
CB : 가만 가만. Rails로 얼마나 쉽게 개발을 할 수 있는지 봤잖아? 그리고 테스팅 프레임웍은 이미 Rails에 포함이 되어 있다고 말했고. 그럼 Rails로 어떻게 할 수 있는 한 번 보라고.
이제 테스트에만 사용하게 될 데이터베이스를 만들게 될거야. 이제부터 사용하게 될 테스트 데이터베이스는 테스트를 수행할때 매번 모든 내용을 지우고 테스트를 수행하게 될거야. 그러니까 테스트를 수행할 때는 항상 테스트베이스에서 하게끔 주의를 해야해. 우리가 만들었던 데이터베이스 설정 기억하고 있어? 자 한 번 열어보자.
[그림 3]
CB : 먼저 데이터베이스를 만들어야 해. 예전에 개발버전의 데이터베이스를 만들던 것과 동일한 방법으로 MySQL에서 하면 되지. 먼저 커맨드 창을 열고 MySQL에 root 유저로 로그인을 할거야. 암호는 아직 설정하지 않았으니 입력하지 않아도 괜찮고. 물론 암호를 설정하는게 맞겠지만 아직까지는 이 시스템에 접근할 수 있는 사람도 나밖에 없으니 나중에 해도 괜찮을 거야.
mysql -u root -p패스워드를 입력하라고 하면 그냥 엔터키를 입력하고
데이터베이스를 만든다.
create database cookbook2_test이런 세미콜론을 빼먹었네.
;"ODBC" 유저에게 권한을 주는걸 잊으면 안되. 문제가 생길 수도 있다고(정말 이상하게도 어떤 윈도우즈에서는 grant를 하지 않아도 괜찮은데, 어떤 윈도우즈에서는 하지 않으면 문제가 발생한단 말이야)
grant all on cookbook2_test.* to "ODBC"@"localhost";자 그럼 다 됐어
exit
[그림 4]
CB : 이제 비어있는 테스트 데이터베이스를 만들었어. 여기에 테이블을 만들어 넣어야 하는데, Rails가 이런 작업들을 우리를 대신해서 다 해주기 때문에 정말 편해. rake의 테스크를 이용하게 되면 개발 데이터베이스에 있는 테이블을 테스트 데이터베이스에 만들 수가 있어.
rake db:test:clone_structure
[그림 5]
Paul : 아무것도 하지 않은 것처럼 보이네요?
CB : 응. rake의 테스크가 어떻게 코딩됐느냐에 따라 다르지. 문제가 없으면 보통 아무 메시지도 출력되지 않아. 쉽게 확인할 수 있는 방법은 데이터베이스 GUI 관리자를 하나 실행하고 확인해 보는거지.
자 여기 우리 개발버전 데이터베이스가 있고
[그림 6]
이건 테스트 데이터베이스야
[그림 7]
Paul : 와 좋네요. 데이터도 같이 복사된 거예요?
CB : 아니. 여태까지 우리가 수동으로 하던 테스트에서는 Production 데이터베이스와 비슷한 수준의 데이터를 필요로 했었지. 또 고객은 항상 보던 데이터를 보고 있을때 테스트 하기가 쉽다고 느껴. 하지만 성공적으로 자동화된 테스트를 하려면 다른 방법으로 생성된 데이터가 필요해. 어떤 사람들은 "가공된 테스트 데이터" 라고 부르기도 하지. 우리가 테이스 데이터베이스에 넣을 데이터는 단순히 테스트를 하기 위해 필요한 데이터 그 이상도 아니고 그 이하도 아니야.
Paul : 아. 계약직으로 고용했던 테스터중 한 명이 그 "가공된 테스트 데이터"에 대해서 말한 적이 있어요. 그 때 보스도 옆에 같이 있었는데 그런 말을 들어본 적이 없다고 하셨었죠. 그래서 그녀에게 무엇인지에 대해서 물어봤는데 이전에 했던 프로젝트에서 만들었던 모든 테스트 계획과 모든 데이터들에 대해서 말해줬어요. 고객들이 모두 돌아가고 나서 프로그램이 정상작동하는지 확인하기 위해서 모든 테스트를 다시 실행했고, 현재 테스트 케이스에 더 자세한 테스트를 추가하고, 새로운 테스트 케이스를 또 추가하고 추가하고. 옆에서 듣고 있던 보스는 아무말도 하고 있지 않다가 "흥미롭군. 우리도 생각 좀 해보야 겠는데". 그리고 나서 자리를 뜨셨어요. 두 번 다시는 보스하고 그 얘기를 하고 싶지 않았어요. 무슨 말인지 아시죠?
CB : 응 알 것 같아. 자네가 말한 것과 지금 우리가 하려는 것과의 차이는 한 마디로 말해서 "레거시 시스템" 이라고 할 수 있어. 레거시 시스템으로 일하는 건 정말 힘든일이야. 레거시 시스템의 단점으로 꼽을 만한게 있다면 자동화된 테스트의 부재라고 할 수 있지. 보스하고 자네가 여기에 처음 왔던 때를 기억하고 있어? 그 때 내가 보스에게 했던 말이 "Rails가 정말 좋은 이유는 개발에 있어서 반복성과 점진성을 이용한다"는 거였어. 그리고 좀전에 Rails에 테스트 기능이 포함되어 있다는 것도 기억하고 있지? 자네가 좀 전에 말했던 안 좋은 상황을 피할 수 있는 방법이 있는데 그건 바로 "레거시 시스템의 빌드를 중단"하는 거야.
역자 노재현님은 어렸을 때부터 컴퓨터를 접하게 된 덕에 프로그래밍을 오랫동안 정겹게 하고 있는 프로그래머 입니다. 특히나 게임 및 OS 개발에 관심이 많으며, 심심할 때면 뭔가 새로운 프로그램을 만들어내는 것을 좋아합니다. 다음에서 웹 관련 개발을 한 후에 현재는 www.osguru.net이라는 OS관련 웹사이트를 운영하며 넥슨에서 게임 개발을 하고 있습니다.
* e-mail: wonbear@gmail.com
* homepage: http://www.oguru.net
TAG :
최신 콘텐츠