NDC Replay

라이브 프로젝트에서 C++로 테스트 주도 개발하기
홍종찬
넥슨코리아
카운터 스트라이크 온라인 팀에서 클라이언트를 담당하고 있는 5년차 프로그래머입니다. 자그만 SI 회사와 이스트소프트 알약 부문에서 근무한 적이 있습니다. 소프트웨어 공학에 관심이 많으며 프로그래밍에 심리적인 요소가 큰 영향을 끼친다고 생각하고 있습니다.
테스트 주도 개발(Test Driven Development, 이하 TDD)에 관심을 가지고 시도해 보았으나, 기대와는 달리 어렵고 고통스러운 경험을 하게 되었습니다. 이 세션에서는 이런 실패 경험들을 공유하고 헤쳐나갈 수 있는 방법을 제시합니다. 많은 한국의 게임 프로그래머가 Windows, C++, Visual Studio를 가지고 프로그래밍을 합니다. 이 환경 하에서 TDD를 하려고 시도했을 때 겪게 될 문제들이 있습니다. 1. 표준적인 TDD 도구가 없습니다. TDD에 대한 책을 보면 대부분 Java+Eclipse 환경이라는 것을 알 수 있습니다. JUnit이라는 테스트 프레임워크가 Java쪽에서는 사실상 산업 표준으로 자리잡아 쓰이고 있으며 대부분의 책에서도 이것을 사용합니다. C++ 프로그래머는 TDD에 대한 책을 보고 공부하더라도 정작 TDD를 지원해 줄 마땅한 테스팅 프레임워크를 알지 못해 방황할 가능성이 높습니다. 2. 위 1번 문제에서 연장되는 문제로, 일명 빨간 막대-녹색 막대라는 것을 보고 느끼기 힘듭니다. Eclipse에서는 JUnit과 함께 배포되는 Add-in으로 시각적인 피드백을 받을 수 있지만 Visual Studio에서는 이런 시각적 피드백을 줄 수 있는 잘 알려진 도구가 없습니다. 3. API 호출을 가짜 객체(Mock Object) 호출로 바꿔치기가 까다롭습니다. C++과 Windows의 수많은 API들은 전형적인 C Native 스타일의 함수로 이루어져 있습니다. Java의 경우 대부분의 API들이 클래스로 만들어져 있어 이것을 가짜 객체(Mock Object)로 바꿔져 API 호출부를 테스트 환경에서 자신이 원하는 대로 조작하는 작업이 수월합니다. 반면 C++에서는 함수 호출부를 클래스로 랩핑을 하고 인터페이스를 추출해내야 하는데다가 Mock Object를 만들어 줄 도구가 따로 구해야 합니다. 4. 신규 프로젝트가 아니라 이미 소스 코드가 존재하는 라이브 프로젝트에서 TDD를 하려고 하면 레거시 코드의 엄청난 종속성때문에 객체를 생성하는 것 조차 어렵습니다. 메소드 하나만 호출해도 거기에 딸려있는 수많은 API 호출들이 연쇄적으로 일어나기 때문에 5. TDD를 하다 보면 종속성 주입(Dependency Injection)이라는 것을 하게 됩니다. 이렇게 되면 클래스가 계층적으로 존재하는 경우 주입해줘야 할 가짜 객체의 양이 크게 늘어나게 되고 결국 실제 코드와 테스트 코드를 만드는 것이 어려워지게 됩니다. 이런 문제 때문에 TDD를 어렵게 느끼거나 중도에 포기하게 될 수 있습니다. 이 세션에서는 위와 같은 문제들 때문에 TDD를 하기 어려움을 인지시키고 해결책을 제시합니다. 각각 다음을 제시합니다: 1. GoogleTestingFramework (줄여서 GoogleTest) 소개 2. 직접 Addin 만들기 또는 본인이 만든 Addin 소스 공개 3. GoogleMock 소개 4. 종속성 끊는 요령 5. Factory로 해결해보기
[새 창에서 슬라이드 보기]
여러분 안녕하세요. 넥슨 CSO팀의 홍종찬입니다. 반갑습니다. 이번 세션은요 테스트 주도 개발에 관한 거에요. 그런데 특히 라이브 프로젝트에서 C++를 사용하는 프로그래머님들을 대상으로 준비해 봤습니다. 제 소개를 간단히 드릴게요. 제 이름은 홍종찬이고 고려대학교 컴퓨터공학과를 나왔고 SI를 1.6년 하고 이스트소프트 알약 커널 개발팀에서 2년정도 있다가 지금은 넥슨 CSO팀 선임연구원으로 있습니다. CSO팀이 뭔지 궁금해하시는 분들이 굉장히 많더라고요. CSO팀이 뭐냐면 카운터 스트라이크 온라인의 약자에요. 카운터 스트라이크라는 게임을 만들고 있고요. 이번 세션에는 테스트 주도 개발을 막 배우신 분이나 아니면 실무에 적용해보고 싶지만 어떻게 될지 모르겠다. 하시는 그런 분들을 위해 준비했습니다. 아직 테스트 개발 프레임워크를 선택하지 못하신 분들을 위해서 GoogleTset를 추천해드리고요 그 다음에 중요한 부분인데, 라이브 프로젝트에서는 레거시 코드 가지고 작업을 하잖아요. 기존의 소스 코드의 의존성이 어떻게 테스트 주도 개발에 악영향을 끼치고 이것을 어떻게 해결할 수 있는지 알아보겠습니다. 마지막으로는 테스트 주도 개발을 하면서 체득한 몇 가지 조언들을 말씀해 드리고자 합니다. 먼저 GoogleTset인데요. 이건 제 얘기인데 제가 전 직장에서 입사한지 얼마 안됐을 때 프로그래밍은 별로 안 시키고 테스트만 몇 주정도 시킨 적이 있었어요. 제가 그 때 많이 힘들었는데 왜 힘들었냐 면 반복 구동적인 그런 테스트를 시킨 거였거든요. 그러다 보니 제가 약간 ‘이런 일을 하려고 회사 왔나?’ 이런 생각을 했어요. 그런데 제가 프로그래머잖아요. 잘 생각해보니까 ‘테스트를 자동화할 수 있지 않을까?’ 그런 생각에서 출발하다가 결국 테스트 주도 개발이라는 것을 알게 됐습니다. 그래서 테스트 주도 개발을 해보자. 그래서 이걸 어떻게 할 수 있을까 해서 책을 사서 봤죠. 이 책을 사서 봤는데 이 책 말고도 따른 책이 몇 권 더 있어요. 한글로 나온 책이. 그런데 문제가 있었어요. 왜그랬냐 하면 제가 C++로 프로젝트를 하고 있었거든요. 그런데 이 책에서는 자바로 설명을 하더라고요. C++에 대한 내용은 전혀 없었어요. 설명은 이런 식으로 나와요. 빨간색, 녹색 이런 주기를 돌아라. 테스트 실패하고 성공하고 리팩토링해라. 그런 얘기 하고 또 소스코드를 보면 이런 식으로, 보면 자바로 되어있거든요. 보시면 @Test라고 되어있어서 자바에 annotation을 사용해서 이런 메소드에 테스트를 걸 수 있다. 이런 식으로 책에서는 설명하고 있었습니다. 아무튼 공부를 잘 했어요. 공부를 잘 하고 실제로 적용을 해보자. 실제로 이걸 해보려고 하면 문제가 있어요. C++사용자들이 뭐가 문제냐 하면 저 @Test라는 것은 Junit이라는 라이브를 사용하거든요. 그런데 C++에서는 Junit이 기본으로 포함되어 있지 않은 거에요. 그러니까 실제로 테스트 주도 개발을 하려면 테스트를 먼저 작성해야 하는데 이 테스팅 프레임워크를 어떤 걸 써야 될지 감이 안 오기 시작하는 거에요. 마치 오토매틱으로 배웠는데 운전면허를 배웠는데 스틱을 잡은 그런 느낌이었죠. 그래서 C++유저들의 첫 번째 장벽이 뭐냐. 바로 테스팅 프레임워크의 선택입니다. 이 문제가 왜 생기냐 하면 책에서 C++에 대한 배려가 별로 있지 않아서 생긴 것이에요. 사실상 자바 쪽에서는 Junit을 업계 표준처럼 사용하고 있죠. 자바 하시는 분들은 테스트 주도 개발한다 하면 당연히 Junit으로 사용한다. 이렇게 생각하는데 C++사용하시는 분들은 어떻게 하시는지 궁금해 했어요. 그래서 많이 알아봤죠. 이 중에 한 3개정도 써봤어요. CppUnit, CppUnitLite, Unit++를 써봤는데 Unit++는 NC에서 사용한다고 하더라고요. 그래서 나중에 C++ 테스팅 프레임워크를 결정하지 못하신 분들에게 제가 GoogleTest를 추천해 드립니다. 제가 처음 발견했을 때 정말 가뭄 뒤에 단비 같은 그런 느낌을 받았어요. 이제 한번 예제를 보여드릴게요. 이게 무슨 예제냐 하면 은행 계좌에 만원을 넣어서 생성해요. 그래서 잔고를 만원이 들어있나 검색하는 로직이에요. 자바로 되어있죠. 그럼 이거를 GoogleTset로 한번 짜볼게요. GoogleTset로 하면 Test annotation이 맨 위에 보시면 @가 아니죠. 저런 식으로 GoogleTset를 사용하고 있고요. 거의 똑 같은 식으로 만원을 넣고 만원이 나왔나 검사할 수 있게 됩니다. 그래서 실제로 돌려보면 컴파일이 잘 되고 이런 식의 결과를 보실 수가 있어요. 이게 visual studio에 통합이 되어있는 그런 라이브러리는 아니에요. 하지만 콘솔에서 이런 식으로 녹색 보실 수가 있다는 거죠. 반대로 실패했을 경우에도 이렇게 빨간색으로 표시가 되고 어디 소스 코드의 어디 행에서 어떤 문제로 발생을 했다 라는 것을 알 수가 있고요. visual studio랑 통합해서 F3을 누르시면 그 문제가 생긴 행으로 즉시 이동하실 수 있어요. 그러면 GoogleTset가 뭐가 좋냐. 먼저 xUnit, 그러니까 Junit과 유사한 테스팅 프레임워크를 xUnit이라고 하거든요. 이 기능을 거의 다 포함하고 있어요. 포함하고 있는 데다가 심지어 구글이 내부에서 프로젝트를 진행하면서 필요하다고 생각하는 기능들을 다 추가했죠. 두 번째로 구글이 개발했다는 건데, 구글이라는 회사가 검색엔진을 만들고 있잖아요? 그러다 보니까 버그에 되게 민감해요. 그래서 이런 걸 쓰고 있는 게 그런 이유가 아닌가 생각이 되고, 크롬 안에 들어가는 라이브러리가 chromium 프로젝트에 관련된 라이브러리가 들어가는데 이런 것들이 전부 GoogleTest를 사용하고 있다고 합니다. 그래서 중요한 것 중 하나가 GoogleMock과의 연계인데 자바 쪽에서는 Mockito라고 해서 가짜 오브젝트를 생성하는 라이브러리가 있어요. 그런데 C++에서는 이런 게 없거든요. 그래서 그거에 대응되는 게 GoogleMock이고 GoogleTest랑 GoogleMock이 굉장히 잘 융합되어서 나중에 소스코드를 한번 보여드릴게요. 그래서 Junit과 GoogleTest 그리고 Mockito와 GoogleMock이 이런 식으로 1:1관계를 보이고 있습니다. 여러분 테스팅 프레임워크를 골랐어요. 이미 고르신 분도 있을 거에요. 그런데 이것만 한다고 끝이냐. 그게 아니죠. 제가 처음에 이건 라이브 프로젝트라고 설명을 드렸잖아요. 여러분이 혼자서 개발하시는 거나 처음부터 개발하는 신규 개발이면 테스트 주도 개발을 적용할 수 있어요. 그런데 여러분이 이미 소스코드를 많이 작성한 상태에서 테스트 주도 개발하려고 하면 많은 문제에 부딪히죠. 진짜 문제는 이제부터입니다. 그게 뭐냐, 바로 의존성이에요. 의존성이라는 게 뭐냐. 제가 간단한 예제로 설명을 드리겠습니다. 여러분은 스카이 다이빙 게임을 만드는 프로그래머에요. 그런데 어느 날 기획자가 와서 이런 기능을 만들어 달라고 합니다. 이번에 새로 나갈 코스튬인데 이걸 만들어 달래요. 그런데 기능이 일반 코스튬이랑 약간 다르대요. 뭐가 다르냐 하면서 기획서를 줘요. 보면 낙하속도가 10%증가한다. 라고 되어있어요. 여러분은 이거를 테스트 주도 개발로 실제 라이브 코드에서 적용을 하시게 됩니다. 어떻게 될까요? 테스트를 먼저 만들어야겠죠. 테스트 주도 개발이니까. 그럼 기존 코드에 추락하는 로직이 있을 거 아니에요? 그 부분을 봅시다. 보면 이런 식으로 플레이어가 추락하는 공식이 있는데 간단하게 설명 드리면 1초에 100m씩 추락한다는 로직이에요. 그럼 생각을 하겠죠. ‘이걸 어떻게 자를까?’ 생각을 해보니까 ‘코스튬을 갖고 있으면 속도를 10%올려주면 되겠구나.’ 생각하겠죠. 그런데 아직 코드를 작성해서는 안돼요. 테스트 주도 개발이니까. 그래서 테스트를 먼저 만들어야겠죠. ‘테스트를 어떻게 만들까?’ 고민을 하게 될 텐데 일단 ‘기존에 100m니까 이번에 110m겠지. 그걸 테스트 하면 되지 않을까?’ 그러면 고도를 1초 지났을 때 고도가 얼마나 바뀌었는지 테스트를 하면 되겠죠. 그런데 문제가 있어요. 추락하는 로직은 테스트가 기존에 존재하지가 않아요. 그런데 여러분이 만드셔야 되요. 그러니까 여러분이 처음 시작을 하는 겁니다. GoogleTest로 테스트를 작성하면 아마 이런 모습이 될 거에요. 플레이어Z를 생성해서 고도를 1000m로 주고 1초를 경과시킨 다음 고도가 900인가 테스트하는 거죠. 그런데 객체부터 생성해야 될 거 아니에요? 객체를 생성하는 로직을 짜보겠습니다. 그리고 컴파일 걸어요. 그러면 어떻게 될까요? 컴파일 에러가 뜨죠. 왜 뜰까요? 이런 플레이어 같은 거는 보통 게임 로직에서 복잡한 로직을 가지고 있어요. 그렇다 보니까 생성자가 간단한 경우가 별로 없어요. 뭘 요구하는지 봅시다. 그러면 server* s를 요구해. 그리고 자기 id를 요구해. 무슨 짓을 하고 있는지 잘 모르겠지만 일단 컴파일을 해야 되니까 괄호를 한번 넣어봅시다. Server* s 요구하는 곳은 NULL 넣고 id는 그냥 비웠어요. 어떻게 되느냐? 또 에러가 나죠. 어떻게 에러가 날까요? 이런 식의 에러가 나겠죠. Access Violation. 딱 보니까 NULL 참조죠. 그러면 제가 이런 상황을 처음 겪었을 때 이걸 제일 힘들어 했어요. 테스트 주도 개발을 하고 싶은데 책에서 다 배웠고, 책에서는 엄청 좋다 이러고, 되게 쉽다, 개발 재미있다 하는데 나는 재미도 없고 짜증만 난다. 그래서 굉장히 힘들었습니다. 이걸 어떻게 해결할 수 있을까요? 일단 플레이어 생성자를 보면 서버에서 어떤 플레이어 인포를 받아온다. 그런데 이때 자기 id를 던져주죠. 이런 식으로 되어있어요. 아마 온라인 게임 개발하시는 분들은 이런 식으로 작성하셨을 거에요. 플레이어가 stand alone, 싱글 게임 아니잖아요. 서버에서 자기 정보를 받아와야 되죠. 그럼 서버 객체를 어떻게 줄 거냐. 진짜 서버 객체 만들어서 id랑 포트랑 입력해서 던져줄까요? 그러면 안되죠. 왜 안될까요? 서버가 살아있어야 되요. 그런데 여러분이 테스트 하고 싶은 건 1초 뒤에 얼마나 떨어졌는가죠. 이게 서버랑 관련이 있나요? 관련 없어요. 심지어 여러분이 진짜 서버를 가지고 있다고 해도 서버 객체를 초기화 하는 코드를 심지어 작성하셔야 되요. 텍스트 코드 안에. 그런 문제가 있어요. 자꾸 짜증이 나요. 생각을 정리해 봅시다. 지금 우리가 뭘 하려고 했는지. 기획자가 낙하 속도 10% 증가하는 코스튬을 가져왔죠. 그래서 플레이어 객체를 생성해 보려고 했어요. 잘 안돼요. 왜 안될까요? 이게 바로 의존성이라는 겁니다. 이런 식으로 서버와 플레이어가 착각할 수 있기 때문에 여러분을 플레이어를 테스트하려면 서버를 끌고 갈 수 밖에 없는 거에요. 어떻게 해야 될까요? 이거를…… 그래서 테스트 주도 개발 입문서를 보시면 간단하게 가짜 객체 쓰세요. 이 정도로만 되어있지, 그렇게 실무에 쓸만한 코드는 잘 설명이 안 되어있어요. 그래서 저는 한번 해기로 했습니다. 가짜 객체를 쓰기로. 가짜 객체가 뭐냐 하면 서버가 있잖아요. 진짜 서버 대신에 가짜 서버를 대신 넣어주면 되지 않느냐? NULL 대신에. 그럼 돌아갈 거 아니에요. 어떻게든. 그런 의미에요. 왼쪽에 보시면 총알이 보이시죠. 진짜 총알. 실탄이 있고 오른쪽에는 공포탄이 있습니다. 여러분이 총이라고 생각하시면 보이는 게 총이에요. 그럼 내가 지금 들어오는 게 실탄인지 공포탄인지 구분할 수가 있나요? 할 수가 없어요. 똑 같은 탄창에 들어가고 발사 할 수 있고 탄피도 빠져나갑니다. 동일한 로직을 하지고 있죠. 그러니까 인터페이스가 동일하다는 거에요. 다이 한번 볼게요. 가짜 객체를 통해서 어떻게 이 문제를 해결할 수 있느냐? 서버에서 플레이어 정보를 받아오죠. 이 서버를 가짜로 갈아치우면 되요. 먼저 서버 헤드를 볼게요. 메소드가 있는데 이런 식으로 메소드가 정의가 돼있어요. Concrete 하게 갈라져있죠. 먼저 이거를 virtual를 붙여줍니다. Virtual에 붙어있으신 분도 있을 거에요. 인터페이스 잘 구현하신 분들은 virtual로 인터페이스 상속받아서 잘 구현이 되어 있는데 아무래도 라이브다 보니까 급하게 구현하셨을 수도 있고 이건 별로 바뀔 일이 없다. 해서 concrete하게 갈라 놓으신 분도 많을 거에요. Virtual 붙이시고요. 상속받는 NULL서버라는 클래스를 생성해요. 그리고 메소드 내용은 비워줍니다. 디자인 패턴 아시는 분들은 이게 NULL 오브젝트 패턴이라는 것을 하실 수 있을 거에요. 그럼 테스트는 간단하게 작성할 수 있어요. 가짜 서버 만들어서 객체 넘겨주면 되요. 그러면 아무 문제 없이 테스트 하실 수 있게 됩니다. 지금까지 한 거 정리해볼 게요. GoogleTest 추천 드렸고, 스카이 다이빙 기획 설명 드렸고, 그걸 하기 위해서 테스트를 어떻게 걸까? 그거에 대한 예제를 하나 보여드렸습니다. 여기서 느껴지는 게 하나 있는데 라이브 프로젝트에서 테스트 주도 개발하기가 뭐냐. 결국은 레거시 코드에 테스트 걸기와 완전 동일한 일입니다. 라는 거에요. 이게 제가 얻어낸 통찰입니다. 그런데 이게 뭐가 의미가 있냐면 테스트 주도 개발은 테스트 먼저 해야 되요. 그런데 레거시 코드에서 테스트 주도 개발하려면 코드가 먼저 있고 테스트가 나중에 나온다는 거에요. 그래서 코드에 어떻게 테스트를 걸 수 있느냐? 바로 의존성 끊기를 해야 한다는 겁니다. 의존성을 끊지 않으면 여러분이 어떤 코드도 테스트하실 수 없을 거에요. 의존성 어떻게 끊는 건데? 방금 NULL 객체 만들어서 모든 필요한 부분마다 NULL 객체 넣어 줄까요? 그럴 수 없을 거에요. 아마도. 여러 가지 복잡한 situation이 발생하거든요. 예를 들어 서버가 실제로 정보를 넣어줘야 될 그런 상황이 올 수도 있어요. 이 사람이 인벤토리에 뭐 좀 넣어주고 이 사람 아이디가 뭐고 친구 누구고 테스트하고 싶으면 서버가 있어야 될 거 아니에요? 이러 때는 가짜 서버 넣어버리면 아무것도 안 하니까 테스트할 수가 없죠. 어떻게 해야 되느냐? 유형별로 접근을 해보겠습니다. 일단 객체를 생성하기에 까다로운 그런 상황이 있을 수 있고 자유 함수니까 전역 함수 호출하는 그런 상황도 있을 수 있고 전역 변수 접근하는 상황도 있을 수 있죠. 일단 코드를 보면서 같이 살펴보도록 하겠습니다. 그 해결 방법으로 세 가지를 제가 드릴께요. 의존성 주입, 가짜 객체, 래핑. . 코드를 보면서 같이 설명을 드릴게요. 먼저 객체 생성 불가 문제에요. 아까 플레이어 객체 생성할 때 굉장히 힘들었잖아요. 바로 이런 유형이에요. 대부분 제가 겪었던 문제는 이런 유형이었어요. 객체를 생성하기 너무 까다로워서, 심지어 생성했더라도 그걸 테스트에 써먹기가 골치 아픈 상태여서 문제가 됐다는 겁니다. 어떻게 해야 될까요? 의존성이 그냥 예를 들어서 생성자가 요구하는 경우도 있을 테고 생성자에서 요구하지는 않지만 여러분이 테스트하고 싶은 로직에 숨겨진 의존성이 있을 수 있어요. 이런 이름 붙은 클래스도 많이 발생해요. 거대한 클래스죠. 갓 클래스라고도 하고, 여러분 소스코드 보시면 몇 천줄, 몇 만줄 되는 소스코드 있을 거에요. 이런 객체는 생성하기가 정말 힘들어요. 동일성이 너무 많아서. 어떻게 해야 되느냐? 의존성 주입이라는 방법을 설명해드리겠습니다. 의존성 주입이 뭐냐면 클래스가 외부의 의존성을 갖고 있잖아요. 바꿀 수가 없어요. 그래서 제가 직접 찔러주는 겁니다. 그게 의존성 주입이에요. 두 가지 방법이 대표적으로 있는데. 일단, 플레이어라는 거대 클래스가 있어요. 그런데 기본 생성자가 정의가 되어있어요. 그래서 여러분이 테스트를 만들 때 그렇게 만들면 되겠죠. 그런데 계속 에러가 나서 뭐가 문제냐, 왜 생성자에 필요한 것도 없는데 문제가 생길까? 봤더니 생성자 내에서 자기가 자기 마음대로 서버 코드를 생성하고 섹션에서 아이디 얻어오고 이런 짓을 하고 있더라 말이에요. 그러니까 이 플레이어가 단일한 객체로 존재할 수가 없다는 거죠. 다 준비 해주셔야 되요. 의존성 주입을 하면 이걸 어떻게 바꿀 수 있으냐. 이거를 생성자가 넘겨주는 겁니다. 이런 식으로. 이렇게 하면 여러분이 생성자를 통해서 가짜 서버, 가짜 섹션을 넘겨줄 수 있게 되겠죠. 이거를 의존성 주입이라고 해요. 그런데 이렇게 하면 해피하겠죠. 그런데 문제가 또 있어요. 여러분 라이브잖아요. 플레이어가 생성되는 코드가 한군데는 아마 아닐 거에요. 수십 군데가 있을 수 있겠죠. 그런데 이런 식으로 마음대로 정의를 바꿔 버리면 여러분이 플레이어를 생성하는 컴파일 에러를 일일이 따라가서 다 수정해야 될 거 아니에요? 그러면 어떻게 하죠? 방법이 있어요. 이놈을 다른 함수로 빼고 처음에 있었던 생성자와 똑 같은 시그니처의 생성자를 만들고 거기다가 아까 하드코딩 되어있던 그대로 넘겨주면 됩니다. 그러면 컴파일도 잘 되고 빌드도 잘 되고 실제 여러분의 라이브 서비스에서도 잘 돌아갈 거에요. 이런 식으로 해결할 수 있어요. NULL 오브젝트 패턴을 사용해서 여러분이 테스트 코드를 이런 식으로 작성할 수 있겠죠. 방금 여러분이 의존성 주입을 사용했기 때문에 이런 코드를 작성할 수 있게 됐어요. 그래서 여러분이 플레이어의 필요한 테스트를 걸 수가 있게 된 거죠. 만약에 여러분이 의존성 주입을 알지 못했다면 플레이어 객체를 생성해 놓고도 테스트할 수 없어서 당황했을 거에요. 또 다른 해결 방법인데 가짜 객체라고 하는 거고요. 설명 드릴게요. 가짜 객체를 만드는 것도 프레임워크가 있어요. GoogleTest에 포함이 되어있지는 않고 GoogleMock이라는 프로젝트에 따로 되어있습니다. 그러면 실제로 GoogleMock이 어떻게 동작하는지 보여드릴게요. 아까 전에 서버에서 플레이어 정보를 얻어오는 그런 코드였죠. 이거를 가짜로 갈아치우면 됩니다. GoogleMock을 사용하시면 이런 문법으로 가짜 클래스를 만드실 수 있어요. MOCK_METHDO2 라고 되어있는데 가짜 메소드라는 뜻이고 2는 뭐냐, 인자가 2개라는 거에요. GoogleTest도 약간 한계가 있는데 인자 수에 맞춰서 이런 식으로 따로 잡아줘야 되요. 그리고 보시면 메소드 이름 나오고 시그니처 나오고, 인자 2개죠. 그런 식으로 작성해본 테스트 코드에요. 가짜 서버와 가짜 섹션을 사용해서 플레이어가 재대로 초기화 되고 있는지 보는 코드입니다. 하나씩 살펴 볼 게요. 먼저 GoogleMock을 사용하시는 분들이면 아마 아실 텐데 모르시는 분들을 위해서 설명을 드리면 EXPECT_CALL, 그러니까 호출이 될 거라고 예상하는 거에요. 세션에 GetPlayerid 라는 메소드가 호출 될 거라고 예상해요. 어떻게 예상하느냐? 뒤에 나와요. 한번 호출될 것 이다. WillOnce라고 되어있죠. 한번만 호출 될 거라는 거에요. 두 번 호출돼도 에러나고 호출 안돼도 에러나요. 이런 식으로 여러분이 실제로 이 객체가 정상적인 동작을 하고 있는지 테스트를 할 수 있어요. 그리고 플레이어 id를 얻어오는데 세션을 여러분이 직접 얻어올 수가 없잖아요? 그래서 가짜로 haha 라는 플레이어 id를 리턴하게 만들었어요. 밑에 보시면 생성자를 호출하는 부분이 있고 마지막으로 생성자 호출 뒤에, 지금 보니까 코드가 잘못 되었는데요. 플레이어를 생성하는 코드가 제일 마지막에 와야 돼요. 보시면 서버에서 GetPlayerInfo를 호출하는지 검사하고 거기에 haha라는 id가 들어오는지 검사하죠. 그래서 이런 식으로 테스트 할 수 있게 되는 겁니다. 똑같아요. GoogleTest 사용하시면 테스트 통과 됐나. 안됐나. 녹색, 빨간색 막대로 보실 수 있어요. 이런 식으로 가짜 객체를 사용하시면 골치 아픈 문제에서 벗어나실 수 있습니다. 거기에 더불어서 이 객체가 실제로 함수를 재대로 호출하고 있는 지를 검사하실 수 있다는 거에요. 그 다음 유형으로 자유 함수 호출이라는 건데 이게 뭐냐면 그냥 전역 함수를 자유 함수라고 해요. 대표적으로 send, receive, CreateWindow, Direct3DCreate9 이런 거 있죠. 그런 거 말고 여러분이 cpp 파일 열어서 저장 공간에 선언하는 모든 함수가 자유 함수입니다. 이 호출이 왜 문제가 되냐면 예를 들어 이게 게임을 초기화 하는 코드인데요. 게임을 초기화 한 다음에, 여러분이 클라이언트 프로그래머면 창 열어서 보여줘야 될 거 아니에요? 그림을 그리고 플레이어 움직임도 보여줘야 되겠죠? 그러니까 CreateWindow가 초기화 하는 부분 어딘가에 있어요. 그런데 이것 때문에 여러분이 이 게임 클래스를 초기화 하는 부분을 테스트 할 수가 없다는 거죠. 어떻게 해야 하느냐? 자유 함수 호출 같은 경우에는 래핑을 하면 됩니다. 어떻게 래핑하냐면 아까 CreateWindow있잖아요? 그거랑 똑 같은 시그니처로 클래스를 만들고 그 안에 virtual로 메소드를 선언해줘요. 보통 인터페이스를 만드는 거죠. 그러면 이 코드가 이렇게 변해요. API 라는 객체를 통해서 호출하게 됩니다. 이 메소드가 하는 것은 똑같아요. 그냥 여기에 들어있어요. 대신에 API라는 파라미터를 받아오게 되는 거죠. 그러면 파라미터를 받아오니까 여러분이 가짜 오브젝트를 쓰든 NULL 프로젝트를 쓰든 입맛대로 할 수가 있게 된다는 거죠. 이런 식으로요. 이것도 문제가 있는데 시그니처 또 바뀌잖아요? 아까랑 마찬가지로 시그니처를 맞춰주는 걸 하나 만들고요. 실제 윈도우 API를 호출하는 식으로 만들어주면 됩니다. 또 골 때리는 게 전역 변수 접근하는 건데요. 전역 변수 접근하는 거는 이중에서 제가 생각하기에는 가장 까다로운 유형이에요. 예를 들어서 인벤토리라는 클래스를 테스트한다고 생각해봅시다. 장미칼이라는 걸 만들어서 인벤토리에 넣었어요. 그 다음에 넣었던 걸 다시 꺼내오는 로직을 만들어서 이놈이 장미칼인지 테스트 해보는 거에요. 그런데 꺼내오는 로직을 보니까 플레이어가 날고 있으면, 예를 들어 WOW같은 경우에는 비행선 타고 있다거나 와이번 그런 거 타고 있으면 아이템을 떨구면 안 되요. 그런 식으로 코딩했다고 칩시다. 아이템이 땅에 떨어질 수 있어서 아무도 못 먹으니까. 라이브 하다 보면 이런 식으로 하드 코딩 많이 해요. NULL 검사해서 예외처리 하고 있겠죠. 날고 있으면 아이템 떨구지 못하게. 그런데 문제가 뭐가 되냐 하면 이게 전역 변수를 참조하고 있다는 거에요. 예를 들어 여러분이 서버가 아니라 클라이언트 프로그래머면 플레이어는 1명이죠. 저 자신. 자신에 대한 객체는 하나밖에 필요하지 않으니까 이런 식으로 많이들 쓰고 계실 겁니다. 그럼 내가 날고 있으면 떨구지 않게 되겠죠. 이런 식으로 어딘가 플레이어를 만들고 전역으로 선언을 해주고 있을 겁니다. 이걸 어떻게 해결하냐면 일단은 싱글톤으로 바꿔줘야 되요. 클래스에 넣어주셔야 하는데, 싱글톤은 여기서 설명드릴 주제는 아닌데 static하게 어떤 변수를 클래스 안에 넣어주시면 되고요. 이거를 생성해서 리턴해주시면 됩니다. 그래서 코드가 어떻게 바뀌냐면, 다 전역 변수를 참조하잖아요? 싱글톤 instance가 참조로 바뀌어요. 그러면 저놈이 전역 객체를 리턴해줄 거에요 이런 식으로 바꾸실 수가 있어요. 이거는 흔히 쓰이는 방법이라서 여러분이 거의 대부분이 알고 계실 거에요. 그런데 이것도 문제가 있죠. 결국 플레이어를 바꾼 건 아니에요. 그냥 싱글톤으로 lift 한 것뿐이죠. 동작은 완전히 동일합니다. 그러면 이 플레이어를 어떻게 조작할 수가 있느냐. 이런 식으로 테스트 instance를 세팅하는 코드를 만들어주시면 되요. 그러면 여러분이 테스트 하실 때만 이 기능을 사용해서 이상한 동작들을 테스트하실 수 있겠죠. 가짜 플레이어를 만들어서 전역 객체가 가짜 플레이어를 리턴하게 만든 다음에 여러분이 코드를 테스트 하시면 됩니다. 이것 말고도 WORKING EFFECTIVELY WITH LEGACY CODE 라는 책이 있는데 여기 마이클 C. 페더스 라는 분이 CPPUnit 이라는 테스팅 프레임워크를 만드신 분이에요. 이게 뭐냐면 Junit의 C++ 버전입니다. 이걸 만드신 분이고 LEGACY CODE에 어떻게 테스트를 걸어야 하는가? 이 책을 보면 LEGACY CODE랑 어떻게 효율적으로 작업을 하는가? 라고 써있는데 실제 내용을 보면 테스트를 걸어야 한다는 식으로 얘기를 하면서 테스트 주도 개발을 설명하고 계십니다. 그래서 LEGACY CODE에 어떻게 테스트를 걸어야 하는가? 그 기술들이 나와있어요. 그래서 마지막으로 제가 시행착오로 얻은 행동요령들. 한번 풀어볼까 합니다. 먼저 막대 주기를 최소화 하라는 거에요. 테스트 주도 개발을 하시면 빨간색, 초록색 리팩토링 하라는 이런 설명을 들으실 텐데 이게 처음 하시면 생각만큼 잘 안돼요. 코드도 없는데 어떻게 테스트를 실패하라는 거야. 그러고, 테스트 실패했더니 어떻게 통과하라는 건지 모르겠고, 특히 라이브는 뭐가 문제가 생기냐면 주기가 빨리 하기가 힘들어요. 왜냐하면 여러분이 테스트를 만드는 시간이 너무 오래 걸리거든요. 아까 가짜 객체 만들고 하는 거 보셨잖아요. NULL 패턴 만들고.. 이런 짓거리를 하다 보면 지금 내가 코드를 만들려고 이 짓을 하는 건지 테스트를 만들려고 이 짓을 하는 건지 알 수가 없어요. 그럼에도 불구하고 막대 주기를 최소화 하는 것이 굉장히 중요합니다. 왜냐하면 여러분들이 집중할 수 있기 때문이에요. 놓치기 시작하면 한도 끝도 없이 여러분이 가짜 객체 만들고 있어요. 수단과 방법을 가리지 말고 이 사이클을 최대한 빨리 돌리셔야 합니다. 두 번째인데 여러분들이 경험적으로 알고 계세요. 리팩토링이랑 코드 작성은 같이하시면 안돼요. 왜 안 되냐. 운전 중에 휴대 전화 통화하는 거랑 비슷해요. 사고 날 위험이 높다는 거죠. 한 군데 집중하지 못하고 코드작성 하다가 리팩토링 하다가 그러다 보면 죽도 밥도 안되고 시간 질질 끌어지고 그런 형상이 비일비재합니다. 저 같은 경우가 그랬는데요. 테스트를 계속 만들잖아요. 테스트를 처음 만들고 통과 시킨 다음에 리팩토링 해야 하는데 리팩토링 하는 게 굉장히 귀찮아요. 그래서 넘깁니다. 그렇게 다음 테스트를 만들죠. 다음 테스트를 만들면 문제가 생겨요. 첫 번째 테스트에서 작성했던 코드 리팩토링 해야 되는데. 그러면 테스트 반쯤 만들어 놨다가 리팩토링 허겁지겁 시작해요. 그러다 보니까 많이 망하는 케이스가 생기더라고요. 그래서 이런 경우에는 여러분이 두 번째 테스트 코드뿐만이 아니라 실제 코드를 짜고 계셨을 거 아니에요? 전부다 롤백하시고 처음에 첫 번째 테스트 통과하신 상태로 만드신 다음에 리팩토링 하셔야 되요. 이것도 제가 경험한 케이스인데 제가 패치 자동화 같은걸 만들어 본적이 있어요. 그런데 패치 자동화 같은 것은 게임 로직이 아니잖아요? 그러다 보니까 파일 읽고 쓰고, 여기 파일 있으면 복사하고, 버전 날짜에 따라서 파일 이쪽에 복사하고 저쪽에 복사하고, 압축하고, ftd 날리고. 이런 식으로 이전 작업을 한단 말이에요? 그런데 이전 작업을 하면 뭐가 문제가 생기냐면, 이걸 제가 테스트 주도 개발로 만들어 보려고 했어요. 패치 자동화 하는 거를. 그러다 보니까 뭐가 문제가 생겼냐, 전부다 Mock으로 만들어 버려요. 전부다 가짜 객체로 만들어야 된다는 거에요. 왜냐, 여러분이 실제로 CPU를 사용하는 코드는 별로 없어요. 다 API호출 범벅이 됩니다. 그러다 보니까 테스트 하나를 만드는 데도 가짜 객체 세팅하는 게 너무 오래 걸렸어요. 심지어 어떤 지경이었냐 하면, 파일 API 호출하는 걸 계속 가짜로 만들다 보니까 제가 파일 시스템 3개를 만들어 버렸어요. 그래서 실제 파일 입출력은 전혀 없는데도 불구하고 파일 복사했으면 여기 파일 있는데 검사하면 ‘파일 있어요.’ 이런 식으로 나오고 파일 용량, 추정 시간 이런 것까지 만든 적이 있었거든요. 이때 느낀 건데 가짜 객체가 만들다 보면 복잡해져요. 그러다 보면 주객이 전도되는 느낌을 받아요. 내가 테스트 주도 개발 하는 거지 가짜 객체 만들려고 하는 건 아니잖아요? 그 때는 가짜 객체를 만드실 때도 테스트 주도 개발로 만드셔야 실수를 하지 않습니다. 그게 안전해요. 말씀드릴 것은 객체 생명 주기 관리인데 여러분 C++를 사용하고 계시잖아요. 그러다 보니까 책에서 나온 거랑 많이 다른 게 있어요. 이게 자바인데 플레이어를 만들어서 리턴해주는 간단한 코드에요. 그런데 플레이어를 생성할 때 서버랑 id를 넣어줘야 되요. 그런데 자바는 어떻게 하냐면 서버 객체 하나 생성해서 클라이언트에 던져놓고 알아서 하세요. 이러면 되잖아요? 그런데 우리는 그럴 수 없어요. 왜 안되냐 하면 이 서버를 누군가는 delete해야 되요. 근데 누가 할거냐는 거죠. 플레이어가 소멸자에서 할 수 있겠죠. 그런데 문제가 생기는 게 서버 생성을 밖에서 했잖아요. 그런데 마음대로 플레이어가 지워도 될까요? 코드 상황마다 다른데 이런 코드를 갖고 계시면 플레이어가 할 수 없게 되죠. 그런데 이런 문제도 있어요. 전역 서버를 바꿔서 클라이언트에 넣어주는 케이스가 충분히 발생할 수가 있겠죠. 그렇게 되면 플레이어가 지울 수 없게 된다는 겁니다. 이런 코드가 혼합이 되어있다면 플레이어가 지울 수 없게 되겠죠. 그러면 이런 건 어떻게 해야 하느냐? 스마트 포인터를 활용하시면 됩니다. 정리해 드릴게요. 테스트 주도 개발하시면서 테스팅 프레임워크를 아직 잡지 못하신 분들에게는 GoogleTest를 추천해 드리고 GoogleTest는 GoogleMock과 함께 훌륭한 C++ 테스트 라이브러리입니다. 그 다음 가장 중요한 내용이라고 강조 드렸죠. 코드의 의존성이 라이브 프로젝트에서 테스트 주도 개발을 어떻게 방해하는지 알아 봤고 이거를 실제 코드를 보면서 이 문제를 어떻게 해결할 수 있느냐? 해서 NULL 패턴 그리고 가짜 객체 이런 식으로 설명을 드렸습니다. 잘 끊어 주시고요. 마지막으로 몇 가지 제가 경험적으로 얻은 건데 막대 주기는 수단과 방법 가리지 말고 최대한 짧게 하라. 그 다음에 리팩토링과 코드 작성은 절대로 같이 하지 마라. 그리고 가짜 객체를 만드는 게 너무 힘들어 지면 가짜 객체도 만들면서 테스트 주도 개발로 만들어라. 그리고 마지막으로 스마트 포인터를 써서 객체 생명 주기를 관리하라고 말씀 드렸습니다. 테스트 주도 개발을 처음에 하시면 많이 힘드실 거에요. 지금도 힘들어요. 1~2년 정도 됐는데 6개월 이상 꾸준히 하시면 테스트 주도 개발이 아무리 힘들어도 아마 그만 두지 못하게 되실 거에요. 왜냐면 테스트가 없으면 불안하거든요. 끝까지 포기하지 않고 테스트 주도 개발 쭉 하시면 견고한 코드와 좋은 설계 그리고 커다란 보상으로 돌아온다는 점 꼭 기억해 주시고 이상 세션을 마치도록 하겠습니다. 감사합니다.
(질문자)_어떤 문제가 있었고 어떻게 해결했다는 건 있는데, 실제 1년정도 하신 결과가 이 프로젝트에 어떤 효과가 있었다는 걸 얘기를 안 해주신 것 같아요. 그게 하나 궁금하고 지금 진행하신 게 개인이 하신 건지 아니면 개인이 시작했는데 그게 팀 전체에 전파가 된 건지 그런 게 궁금합니다. 
(발표자)_어떤 게 좋았느냐? 실제로 적용 했느냐? 그 다음에 제가 적용했느냐? 팀에서 적용했느냐? 이런 거죠? 일단 제가 사실대로 설명을 드릴게요. 지금 몸 담고 있는 곳에는 이걸 하고 있지 않아요. 물론 패치 자동화는 제가 테스트 주도 개발로 한 거고요. 이건 python으로 했어요. 그런데 제가 전 직장에서는 이걸 했습니다. 그 때 어떻게 했냐 하면 말씀 드리다시피 제가 입사한지 얼마 안 돼서 테스트를 계속 시켜서 힘들었어요. 그래서 ‘그냥 나 테스트 자동화 할거야.’ 해서 저 혼자 그냥 한 거에요. 백신 개발이었는데 자동으로 안 끼고도 테스트 할 수 있게 만들어 보려고 한 게 최초 시도였어요. 그러니까 저 혼자 했는데 하면서 옆 사람한테도 보여주면서, 그 때 사내에서 개발자 세미나도 했었거든요. 그 때도 “테스트 주도 개발 하자.” 이런 식으로 전사 프로그래머한테 설파도 했었고 그러다 보니까 바로 피드백이 왔어요. “너 미쳤냐” 이런 피드백도 왔었고요. 본부장님도 와서 “너 지금 라이브 코드인데 너 지금 테스트 주도 개발 하겠다고 이런 짓 하지 말고 일해라.” 아무튼 눈물도 쏟고 이런 적이 있었는데 결론적으로 말씀 드리면 제가 나오기 직전까지 테스트 주도 개발 하다가 나왔어요. 그때 하다가 몇 명이 전염이 돼서 같이 하기 시작하더라고요. 그냥 제가 하는 거 보고. 코드 짜고 있다가 뒤에서 보고 “너 이게 뭐냐” “이거 테스트 자동화 되요.” 보라고. “오, 짱인데. 나도 한번 해볼까?” 이거 어떻게 하는 거냐고, 세팅하는 거부터 가르쳐 달라고 해서 제가 GoogleMock 라이브러리 빌드하셔서 링크해서 쓰시면 되요. 그러면서 한번 더 했어요. 팀 내에서 테스트 주도 개발하기 세션을 한번 더 진행했었고요. 물론 좀 오래되고 높으신 분들은 안 좋아하는 분이 계세요. 그럼에도 불구하고 제가 계속하고 옆에 사람들이 계속 하는 것을 보니까 “그래. 괜찮은 것 같아. 한번 해봐.” 이런 식으로 말씀하시더라고요. 그래서 제가 나왔을 때쯤에는 3명, 4명정도 하기 시작했었고, 그 말이 뭐냐 하면 SNV에 commit 될 정도로 정착이 된 상황은 아직 아니었어요. 나오고 나서 최근에 들리는 소문에 의하면 다 하고 있더라. 라고 하더라고요. 그리고 효과는 저 개인적으로 효과는 정말 힘들었고요. 처음에는. 하다 보면 말씀 드렸다시피 ‘이걸 내가 왜하고 있나?’ 이런 생각도 들었고, 하튼 되게 힘들어요. 라이브에서 하면 그런데 진짜 마음을 독하게 먹고 반년을 했어요. 이제 손을 못 떼는 거에요. 중독이 돼서. 힘든 거 아는데, 술 먹고 다음날 술 먹는 것처럼 계속 하게 되더라고요. 저한테 어떤 변화가 있었냐 하면 코드를 짤 때 의존성 최대한 제거하려고 노력을 합니다. 그러다 보니까 OOP 디자인 패턴이 자동으로 나와요. 그게 저한테 나오는 가장 큰 남는 게 아닐까? 이렇게 생각을 합니다
(질문자2)_테스트 주도 개발이 힘든 걸로 알고 있는데 어디까지가 적용을 해보셔서 테스트 주도 개발을 해보셨는지? 그러니까 물리적인 것들이 들어가거나 이런 것을 할 때는 힘들어 보이거든요. 제가 예상하기에는 테스트 주도 개발로 하기에는 힘들지 않을까라는 생각이 드는데 어디까지 적용을 해보신 건지가 궁금하고 효과가 어땠는지 궁금합니다
(발표자)_일단은 충돌 검사 같은 경우는 어떻게 하냐면, 제가 집에서 개인적으로 게임 만들면서 테스트 주도 개발로 했었거든요. 그러다 보니까 물리가 들어가잖아요? 어떻게 테스트를 했냐. 물리 충돌 같은 경우는 하드 코딩이 되는 경우가 많아요. 실제로 프레임이 돌고 타임이 흐르면서 전 프레임과 지금 프레임의 어떤 변화가 있었는지 검사를 하고 충돌차를 검사하게 되죠. 이걸 테스트 주도 개발로 하려면, 저 같으면 이렇게 할 거에요. 충돌이라는 상태를 가진 객체를 만들어요. 그래서 그런 게 있으면 시간에 종속 받지 않죠. 프레임을 돌릴 필요도 없고요. 그 놈을 사용해서 가짜 충돌 로직을 생성해서, 예를 들어 두 플레이어를 이동시킨 다음에 충돌 객체가 생성 됐는지 보고 그게 제가 원하는 상태로 나왔는지 그런 식으로 검사를 하게 될 것 같아요. 
(질문자2)_어느 상황까지 테스트 주도 개발로 해보신 건지?
(발표자)_애매한데, 전 직장에서 한 거라, 예전 섹션이라서 말씀 드리기가 그런데 설명을 해드릴 게요. 윈도우 API 컨트롤 하는 로직이 있었는데 그 로직을 다 분리해서 완전히 standalone 하게 윈도우 API 로직의 영향을 받지 않고 테스트를 할 수 있는 정도까지 해봤습니다. 효과는 어땠냐 하면, 제가 그거를 왜 했냐 하면 제가 그거를 매일 테스트 했어요. 4시간. 코드 한 줄 짜고 테스트하고 그랬는데, 윈도우 API 같은 경우, 예를 들면 이런 거에요. 하드디스크 용량이 부족해요. 이런 경우는 어떻게 예외처리가 될까요? 그럼 이걸 테스트하려면 어떻게 되요? 하드 꽉 차야 될 거 아니에요? 이런 문제를 해결하기 위해서 제가 이런 걸 도입했었는데 되게 까다로운 문제에 대해서 예외처리하기가 쉬웠어요. 이런 효과가 있었습니다. 
(질문자3)_아까 전에 createwindow를 API로 따로 flex만들어서 하셨더라고요. 그런데 visual studio에서 사용하면 그냥 windows API를 사용할 수 있는 게 아닌가요? 실제로 창을 띄워서 그것을 그리고 하는 것까지 테스트하면 되는 게 아닐까? 메인 클라이언트가 뜨지 않아서 로컬로 fake해서 사용하시는 건가요?
(발표자)_그런 식이죠. 이건 예시를 드린 거고. Windows API 라는 게 createwindow만 있는 게 아니잖아요? 예를 들면 file …… 이 있을 수도 있는 거고.
(질문자3)_저는 아까 전에 파일 시스템을 가상으로 만드셨다고 했는데 실제 파일을 쓰지 않고 왜 그렇게 하셨는지.
(발표자)_사실 저도 위험이 많았는데 그냥 어차피 테스트 코드니까 그냥 폴더 하나 만들어서 그 안에서 테스트하면 되지 않느냐 생각을 했었어요. 했었는데 훈련하자는 의미에서 일부로 가짜 객체로 만든 것도 있었고요, 저 자신을 트레이닝 하기 위해서. 그것도 컸고 하드디스크 라는 게 실제로 읽고 쓰다 보면 그걸 관리하는 코드를 만들어야 되요. 골치 아프거든요. 그리고 이 테스트 코드를 남한테 줄 수가 없게 되요. 환경이 다르기 때문에. 그래서 제가 가짜 객체로 전부 발랐습니다.
(질문자4)_먼저 테스트 코드를 작성하면 이 코드를 어디에 둬야 하는지가 먼저 궁금하고요. 그리고 예시로 보여주신 게 새로운 걸 추가할 때 테스트 코드를 작성하는 걸 보여주신 거잖아요? 그런데 라이브 같은 경우는 기존에 추가된 게 많을 건데 그것들을 다 테스트를 만들어야 하는지 아니면 만들지 않고 새로 추가하는 거에만 테스트를 만들면 의미가 있는지 궁금합니다.
(발표자)_사실 만들었는데 주제랑 별로 와 닿지 않는 문제라서 뺐거든요. 프로젝트 설정하는 방법이 있어요. GoogleTest로 작업할 때 저는 이런 식으로 하는데, 혹시 테스트 대상이 라이브러리 .lib이나 .dll이나 .exe 안에 있나요?
(질문자4)_라이브러리를 말씀 드리는 게 아니라 게임 코드 전체적으로 많은 것들이 있는 데…
(발표자)_그 게임코드가 담겨있는 게 .lib이나 .dll이나 .exe 하나일 거 아니에요? 
(질문자4)_그냥 소스 코드 전체적으로 말씀 드리는 건데…
(발표자)_조금 애매하긴 한데 소스 코드가 어딘가에는 binary가 빌드 될 거 아니에요? 그걸 .lib이라고 해봅시다. 제가 미연시 만들다가 한 건데 구조가 어떻게 되냐 하면 결론적으로 말씀 드리면 테스트 프로젝트는 진짜 코드랑 분리하셔야 되요. 왜 분리해야 하냐면 라이브니까 테스트 코드를 같은 프로젝트에 빌드 된 것이면 유저한테 나가요. 그 코드가 빌드된 상태로. 그러니까 안 되겠죠. 당연히 프로젝트는 분리하셔야 하는 거고, 프로젝트를 분리했는데 테스트를 어떻게 되는가에 대해서는 일단은 헤더를 참조하고 라이브러리를 링크하면 여러분이 다른 프로젝트에도 자기 소스처럼 쓸 수 있잖아요? 그런 식으로 분리해서 작업했어요. 그거는 하지 마세요. 그러면 안돼요. 왜냐면 라이브 코드를 만든 시간보다 더 많이 걸릴 거에요. 몇 년이 걸릴 수도 있어요. 그러지 마시고 변경이 잦은 부분 있잖아요? 제가 아까 말씀 드렸잖아요. 내가 너무 테스트하기 짜증나서 만들었어요. 그 부분에 대해서. 그런 부분이 분명히 있을 거에요. 변경이 80%가 발생하는 부분이 있을 거에요. 거기만 어떻게 끌어내서 만드세요. 저는 좋은 것 같아요. 그렇게 하시고.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
