-
Notifications
You must be signed in to change notification settings - Fork 10
/
0137.txt
242 lines (242 loc) · 19.3 KB
/
0137.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
안녕하세요. 포프입니다.
음... 오랜만에 정상 머리로 돌아왔어요.
여태까지 막 피구왕 통키
홈리스 이런 거 하다가
오랜만에 정상 머리로 돌아와서 좀 이번 포프티비는 차분하게 진행을 할리가 없겠죠?
음.. 오늘은 유닛 테스트에 대해서 좀 얘기를 하려고 해요.
예전에 잠깐 다른 편에서 얘기를 했나? 안 했나? 기억이 안 나요. 솔직한 예기로
포프티비 많이 만들다 보니까 그리고 가끔 사람 만나다 보면 똑같은 얘기를 해요.
재가 믿고 있는 거 재가 아.... 뭐....
뭐는 옳고 뭐는 나쁘다 저만의 소신이 있으니까
그걸 사람들한테 말하다 보면 어느 순간 포프티비를 만드는 순간 이 말을 한 것도 같고 안 한 것도 같은데
어쨌든 아.... 그냥 할게요.
사실은 다른 예기를 먼저 하려고 했는데 어차피 유닛 테스트 예기이기 때문에
그럼 원래 다른 예기 할려던거부터 하죠.
왜냐하면 그거 듣고 재가 예전에 유닛 테스트 예기한 거 혹시 들으신 분 있으면 끊고 안 들으시면 되니까
제가 이제 웹 회사를 다니다 보니까 C# ASP.NET 이걸 되게 많이 써요.
그리고 C# ASP... C#이라고 해야겠죠.
C#의 장점이 아무래도 리플렉션 시스템이 잘 되어 있기 때문에..
실행하는 순간부터 모든 거의 음... 뭐라 그럴까
음..
오브젝트 타입이라던가 뭐 멤버 타입이라던가 뭐... 클래스에 관한 모든 정보를 알 수가 있는 장점이 있죠.
물론 성능의 단점이 있지만.
그 C#의 장점 중에 하나가 그런 거니까 리플렉션(Reflection)시스템
그래서 이제 그 덕분에 C#에서 테스트 코드를 짜는 것도 굉장히 쉽더라고요.
예를 들어서 저는 Visual Studio에서 만약에 유닛 테스팅을 하려면
말 그대로 테스트 프로젝트 하나 만들고 나서 뭐 그냥 에트리뷰트(attribute) 있잖아요.
이렇게 각 괄호([ ]) 써가지고 하는 거
거기에 무슨 이게 테스트 메서드라고 해주고 이름 정해주고
그리고 그냥 코드 안에서 실행하고 싶은 테스트를 적어주고
assert 아시죠 assert가 이제 그.........
테스트의 assert가 있어요. 그 어썰트 해가지고 이게 이 값이 맞냐 라고 확인을 하고
그게 아니면 자동으로 테스트가 fail이 돼서 결과가 나오게 해 주는
그리고 테스트 실행은 간단하게 그냥 Visual Studio에 있는 Test Explorer(테스트 탐색기)로 가 가지고
그냥 뭐 전체 테스트다 실행시키거나 실행 하나만 시키거나 하면 되더라고요.
물론 어.. 되게 편하다는 생각을 많이 했어요.
아 그래서 재가 뭐.. 게임 쪽에서는 보통 잘 안 하잖아요. 사실은 유닛 테스트를 그래서 안 하다가
요번에 웹 쪽으로 와서 유닛 테스트를 몇 번 해보고 나서 아 유닛 테스트 굉장히 짜기 편해졌구나
아.. 그렇게 생각을 하다가 C++를 생각을 해본 거죠.
그러다가 이제 예전 같은 경우에는 이제 Visual Studio 자체에서 Test Explorer 제대로 지원을 안 해줬을 때
무슨... 여러 가지 테스트 플랫폼이 있었어요. 유닛 테스트를 쓸러면은
이런 이런 이런 코드를 써가지고 뭐 앞에 이런 거를 뭐...
좀 복잡했고 Preprocessor를 붙여주느니 전처리문
그래서 막 별별 이상한 짓을 해서 유닛 테스트를 해야 됬었는데
어찌 보면은....
괜찮은 방법이기도 했는데
뭐든 간에 새로운 시스템 하나를 집어넣고 새로운 전처리문을 집어넣기 시작하면은 전체 시스템이 복잡해지고
그만큼 뭔가 하나 망가지는 것도 많고
뭐 하나 설치할 때마다 또 새로운 사람 들어와서 뭐 셋업 할 때마다 설치해할 것도 많고
그래서 개인적으로는 굉장히 피하는 편이었거든요.
그래서 가능하면은 모든 설치를 최대한 적게 하고 효과를 낼 수 있는걸 되게 좋아했는데
다행히 이제 Visual Studio 2012에도 있었던 거 같고 2013에는 확실히 있고요.
있는 기능 중에 하나가 테스트 익스플로러고 아까 C#에서 말씀드렸듯이
그렇게 거의 간단하게 그냥 비주얼 C++용 프로젝트 테스트 프로젝트 만들고 나서 거기서 테스트 메서드 정해주고
그냥 하는 것만으로 컴파일만 하면은 곧바로 실행이 되더라고요.
아... C++에서도 굉장히 유닛 테스트 쓰기가 편해졌다.
그냥 Visual Studio 쓰시는 분들은 거기서 쓰시면 되더라고요.
물론 Visual Studio를 안 쓰시는 분들은 다른 뭐 아까 말씀드렸던 시스템을 인테그레이션 하고 이래야겠지만
전 개인적으로 이제 뭐 게임 만드시는 분들은 대부분 Visual Studio를 쓰실 테니까.
아니면은 다른 분야 계시더라도 Visual Studio를 쓰시는 분이 계시면 이걸 쓰시면 정말 편할 거 같아요
특히 따로 할거 없고 물론 크로스 플랫폼은 안 되겠죠 당연히
그래서 거기까지가 재가 따로 하려고 했던 예기고
아직까지도 C++를 만약에..
쓰시는데 유닛 테스트를 한번 해보고 싶었는데 아 복잡해서 안 하셨던 분들
한번 그렇게 셋업 해서 해보세요. 굉장히 편하고 빨라요. C#은 너무너무 편하고 빠르고
그러면 이걸로 원래 유용한 정보는 끝
그리고 그다음에 제가 하려는 말은.
제가 믿고 있는 유닛 테스트의 효용성이라고 해야 되나요?
그걸 말씀드릴게요
최근 들어 어떤 또 뭐라 그럴까
어떻게 보면은 순수 주의자고 그러니까 저흰 뭐 한국말로 순수 주의자는 아닌 것 같은데
아... 여기서는 그냥 Purist(순수주의)라고 그러거든요.
굉장히 퓨어한 걸 원하는 그런 엔지니어?
그런 사람일 수도 있고 아니면 뭐 정치만 하는 사람일 수도 있는데
굉장히 유닛 테스트를 강조하는 사람을 만났어요.
모든 프로그램은 모든 코드는 유닛 테스트가 되어야 한다.
유닛 테스트를 해서 무슨 Code Coverage라고 하거든요. 실제 테스트되는 코드가 몇 프로냐?
그 코드가 거의 뭐 90프로 100프로가 돼야 된다 그런 얘기를 하는 사람을 봤는데
제가 여태까지 봐온 사람 중에 그런 뭐 예전에...
예기했나? 기억이 안 나는데 빌드 시스템 예기할 때도 옛날에 한번 했던 것 같고
그런 Purist 마인드를 가지고 있는 사람들이 굉장히...
효용성이라던가 효율성? 실용성? 등을 다 저해시키고 회사 돈을 엄청 낭비하는 경우를 많이 봤어요. 솔직한 예기로
그래서 저는 일단은 그 사람 의견에는 반대예요.
이게 유닛 테스트가 필요한 곳이 있어요. 왜냐하면은 전에 왠지 말한 것 같아요. 예전에
유닛 테스트가 필요한 곳이 뭐냐면 정말 핵심적인 분분이 있잖아요.
예를 들어서 금융권이라면 계산하는 그런 코드 로직이라던가
거기서는 말 그대로 몇 센트 몇 원만 틀려져도 사람들 수백 명 수백만 명 더하면 손실이 크니까
그런 부분이라던가 아니면 사람의 생명을 좌지우지하는 그런 뭐 군사? 기업? 그런데는 100프로 다 해야죠
아니면은 뭐 메디칼 쪽? 의료기기 쪽? 그런데는 당연히 100프로 하는 게 좋죠
그래서 이게 유닛 테스트가 하는 건 그거예요.
이 함수를 만들어 두고 이 함수와 이 테스트를 통과하게 해났어요.
그러면은 나중에
만약에 실수로 다른 사람이 코드를 바꿨을 때 이 테스트에 fail을 하기 때문에
곧바로 아 뭔가 버그를 만들었다는 걸 곧바로 캐치를 할 수가 있는 거죠.
그래서 이제 그런 시스템이 당연히 있는 거는 당연히 좋은 데가 있어요. 그런데
결과적으로는 유닛 테스트를 작성하는데 드는 비용과
그리고 나중에 왜냐면 사람이 시간이 들어가니까
그 비용과 실제 버그가 나서 고치는데 드는 비용을 따져봐야 하는 거죠.
그러니까 만약에 정말 뭐 군사기계나 건축 쪽 같은 경우는 처음부터 굉장히 Requirement(요구사항)가 확실하게 나와 있거든요.
그래서 이제 그런 부분이라면 당연히 그 부분에 대해서 Requirement에 맞춰서 유닛 테스트를 만들어 두고
기능을 만들면서 유닛 테스트를 돌리는 방법이 있어요.
아니면은 그 아키텍트 그러니까 전체 시스템 디자인하고 클래스 다이어그램 다 만드는 사람과
API 설계하는 사람과 실제 구현하는 사람이 다른 경우
그런 경우도 당연히 유닛 테스트가 있으면 좋아요.
왜냐하면 API를 미리 만들고 나서 유닛 테스트를 만들어 놓은 다음에
네가 구현을 했을 때 이 유닛 테스트를 통과해야 된다는 개념도 있고요.
그런데 재가 지금 있는 웹 쪽도 그렇고
실제 게임 쪽도 그렇고 Requirement라는 거 자체가 정해진 데가 아니에요.
계속 바뀌고 그게 바뀔 때마다 굉장히 많은 부분을 갈아엎어야 하고
실제 어떤 함수의 그.. behavior(행동)를 바꿀 때도 있어요.
API를 바꿀 때도 있고
그럴 때마다 유닛 테스트를 계속 업데이트를 해줘야 되는 게 과연 올바른 것인가를 생각하게 되는 거죠.
그리고 어떤 경우에는 그런 Requirement가 바뀔 때마다 유닛 테스트가 테스트하는 그..
로직 자체도 바뀌기 때문에 그거를 바꾸다 보면은 거기서 버그가 생길 수도 있고
어떻게 보면은 시간낭비가 더 많을 수가 있다는 예기예요.
그렇기 때문에 저는 기본적으로는 유닛 테스트......는
정말 핵심적이고 정말 안 바뀌는 부분
그런 부분에는 쓰는 게 맞다고 보지만 그게 아니면은 차라리 안 쓰는 게 오히려 시간을 안 끼다고 보거든요.
그리고 어떤 의미에선 요즘 *Scrum 많이 하시듯이
*(애자일 소프트웨어 공학 중의 하나)
그 뭐라 그래요. 뭐 계속 빨리 변화하고 빨리 adapt(적응) 하고 뭐에 적응하고
빨리 iteration(반복)해가지고 계속 더 발전시킨다는 개념이 요즘 강하잖아요.
그런데가 있을수록 유닛 테스트는 조금씩 더 힘들어지는 거긴 해요.
그래서 유닛 테스트 정말 100프로 주장해온 사람과 일해 봤을 때 느낌은 이 사람들은
비즈니스......... 를
잘 이해 못하고 정말 실용적인 생각보다는
그냥 엔지니어로써 모든 거를 완벽해야 돼 그 마음가짐 완벽하고 싶은 그런 욕망?
그거를 너무 잘못 써가지고 회사의 돈을 낭비하는 경우죠.
근데 뭐 아까 말씀드렸듯이
디펜스 쪽? 군사 쪽? 메디칼 쪽은 말이 돼요.
그리고 그쪽은 심지어는 어느 정도까지 하냐면 예전에도 말했을지도 모르겠는데
재가 아는 연구 모 디펜스 회사에서 일하다가 오신 분이 계시거든요.
그분이 하는 예기는 그거였어요.
그 디펜스 쪽은 매일 아침마다.. 그 일단 작업을 버추얼 머신 안에서 해요.
그러니까 내 컴퓨터에서 하는 게 아니라 공통된 버추얼 머신 이미지 안에서 해요.
왜냐하면 모든 사람의 환경이 똑같아야 하니까
내가 뭔가 다른 프로그램을 깔아서 그게 다른 프로그램의 영향이 미쳐가지고 그게
내가 짜 놓은 프로그램이 뭐 behavior를 바꿨는데
실제 최종 머신에 들어가는 environment(환경)하고 달랐을 때 거기에서 버그가 생기면은
미사일 쐈는데 엉뚱한 나라 가 가지고 죽을 수도 있으니까
그래서 그 버추얼 머신을 쓰고 그리고 또 재밌는 거는
버추얼 머신 이미지도 매일마다 리 이미징을 해요.
원래 있던 그 이미지로
한마디로
자기가 실수로 다른 걸 다운로드하였거나 이런 경우 있잖아요.
자기가 뭘 바꿨다거나 그런 게 없게 그러니까 모두 똑같은 환경에서 일하고 모두 똑같은 코드가 나왔을 때
그 코드가 모든 머신에서 똑같이 돌아간다는 보장하에 시작하는 거예요.
그리고 또 재가 아는 다른 친구의 뭐 누나의 남편은 굉장히 큰 항공회사에 다녀요.
그 항공회사가 되게 큰 회사예요. 뭐 이름 들으시면 딱 알정도의 회사인데 뭐 그래 봐야 두 개밖에 없겠죠. 사실은
둘 중에 하나인데
그 회사는 엔지니어도 정말 많은데
일 진행이 너무 느려요. 그 이유가 뭐냐면
모든 거에 그런 유닛 테스트랑 그런 걸 해야 하고, 모든 거에 굉장히 까다롭게 검토를 해야 하는 곳이거든요.
잘못해서 비행기 날랐다가 뭐 하자 있어가지고 추락할 수도 있잖아요.
테스트에서 안 잡혔는데 나중에 그런 경우
그리고 여기는 아직까지도 Visual-Basic 6을 써요.
'비주얼 베이식육'을 그 이유는
만약에 Visual-Basic. NET이나 이런 걸로 넘어갔을 때 많이 짜야되는 코드가 다시 많으니까
그 코드를 짜면서 나오는 버그가..
버그가 나오잖아요. 아무래도 새로 코드를 짜고 옮기다 보면은 그거를.....
용납을 못하는 거예요.
이미 돌던 라이브러리 이런 거를 이미 돌던 거 버그 이미 다 잡아놨고 잘 도는 거를
잘 도는 거를 새로운 거를 해가지고 버그를 새로 (?????)해가지고 거기서 문제가 생기는 거를 참을 수가 없으니까
이런 신기술? 좀 더 사용하기 편한 IDE 이런 거 다 무시하더라도
그냥 우리는 안전하게 가야 된다는 거다 해서 여전히 Visual-Basic 6을 쓰고 있어요.
그래서 재가 말한 게 그거예요. 정말 Purist의 마인드로 가려면
그런 회사가 더 어울릴 수도 있어요.
그런데 웹이나 제가 볼 때 이쪽 그... 게임 쪽이나 웹은
그건 확실히 아니에요.
저희는 뭐든 간에 빨리 빨린 변하는 게 중요한 거고
그래서 그거에.. 소비자의 입맛에 맞게 빨리 변하는 게 가장 중요하거든요.
그리고 실제 뭐 엄청나게 뜨고 유명한 그런 제품의 코드 베이스들을 보면은
대부분 코드 자체는 그렇게 뭐 깔끔하거나 훌륭한 품질의 코드는 아니에요.
왜냐하면은 그 사람들은 말 그대로 빨리빨리 먼가 내놓는 게 중요했기 때문에,
물론 그렇게 너무 개판 치면서 아무 생각 없이 빨리 만들다 보면은
몇 년 동안 성장을 하다가 그 순간에 성장이 늦어지지요.
왜냐하면은
코드 하나 고치는 게 너무 힘들어지는 경우가 있거든요.
그런 경우는 뭐 그런 경우도 몇 번 보긴 봤는데 결과적으론 밸런스가 중요한 것 같아요.
그래서 뭐 말 그대로 facebook의 예만 보더라도
이 친구들은 모든 걸 PHP로 짰고
처음에 코드 기반이 그렇게 뛰어난 코드 기반도 아니었고
그래서 버그도 되게 많았잖아요. 한동안
그걸 잡으려고 한동안 꽤 많은 노력을 했지만
그래도 이 친구들의 장점이 뭐였냐면
facebook도 그렇고 twitter도 그렇겠지만 A/B테스트 그런 게 있잖아요.
예를 들어서 새로운 기능을 구현했는데
이 기능이 과연 좋은지 안 좋은지 모르니까
아.... 어떤 유저 그룹에는 예전 기능을 보여주고 또 다른 유저 그룹엔 새로운 기능을 보여줘서
그 사람들이 과연 어떻게 이걸 받아들이냐
더더욱 클릭을 많이 하느냐 이런 걸 봐가지고 그중에서 나은 방법을 찾는 방법
결과적으로는
어찌 보면은 Purist의 마음가짐 하고는 되게 다른 거예요.
Purist의 마음가짐은 모든 거를 확실하게 만들어 놓고 Requirement를 확실하게 만들어 놓고 설계 잘한 다음에
이 설계 끝난 다음에 자! 제품 끝! 이것인 반면에
그게 아니라 이렇게 뭔가 사람들의 반응을 봐가면서 테스트를 해가면서 하는 그런 방법은
최대한 어떻게든 빨리 테스트할 수 있는 환경을 구축해서 사람한테 제공하고 나서
이게 괜찮다고 보면은 그거대로 가는거죠.
그리고 그거대로 만들고 어느 정도 당연히
해킹만으로는 솔직히 코딩이 어떤 제품도 1년 이상 2년 정도 넘어가면 유지하기가 힘들다고 보거든요.
그래서 그게 해킹이 안될 정도로 적당히 다듬어서 서비스를 하다가
또 다른 새로운 아이디어가 있으면 똑같이 또 만들어서 A/B 테스팅해서 계속 가는 이런 방식이 맞는 건데
그래서...
그런 Purist의 마음가짐? 그런 거를 보면서 참 가끔은.....
갑갑해요. 이 사람들은 왜 여기서 돈을 낭비하고 있나
차라리 자기들이 정말 Purist 되고 그렇게 자기가 실력이 될 거라고 믿으면
좀 더 힘든 데를 가지 그러니까 어중간한 데서 걸쳐서 그냥 .
나는 Purist다 나는..
나는.. 너네들이 하지 않는 그런 뛰어난 엔지니어링 길을 가고 있다 이거에 뭐 만족을 느끼며...
자위를 하고 있는 거 같기도 하고
그냥.. 그래서 제가 생각한 유닛 테스트는 그런 거예요.
사실은 웹이나 그런 뭐......
게임 프로그래밍 쪽에서 유닛 테스트의 가치가...
저는 한 20프로 정도 있나?라고 봐요. 사실은
코드에서 커버리지 20 프로 되면 굉장히 유닛 테스트 많은 거라고 보거든요.
저희 쪽에서 한 10프로만 돼도 상관없을 거 같고
또 한가지 재밌는 점은....
뭐....
제가 게임 뭐 엔진 코드도 꽤 많이 작성하고 그랬지만
어떤 엔진도.....
그렇게....
장수를 하는 엔진도 없는 것 같아요.
한 5년 정도 쓰면 잘 쓰는 거 같은 그런 느낌?
뭐.. 길면 10년?
그래서 저희가 모든 제품을 만들 때 저희는 5년 동안 이 제품 이 코드를 잘 쓸 수가 있냐를 생각하고 시작을 해야 하는 것 같아요.
5년 뒤에는 다시 한번 또 리펙토링을 하게 되고 바꾸게 되고 이러니까
그런데 이제 5년 정말 갈 정도의 코드라면은 유닛 테스트 박는 거는 좋죠.
그리고 5년 동안 안 바뀔 코드라면
그런데 5년 동안 저희가 매년 한 번씩 바뀔 코드라고 그러면
유닛 테스트는 조금 문제가 있는 것 같아요.
문제가 있는 게 아니라...
있으면 당연히 좋은데
그걸 작성하는 시간과 유지하는 시간을 따져 봤을 때 차라리
뭔가 빨리빨리 내놔서 좀 더 현실 변화에 빠르게 적응하는 게 맞는 거 같다는 게 저의 생각이에요.
그래서 한 저의 가이드라인은
뭐 게임엔진이라던가 웹 코드에서 유닛 테스트는 대강한 10프로에서 20프로 정도가 맞지 않다 싶어요. 뭐...
50프로 이상은 죽어도 아닐 거고 뭐..
30프로 40프로도 가능하긴 할 거고.. 근데.. 제 생각엔 10프로 20프로
그 정도로 유닛 테스트 예기를 마치고
뭐 중요한 거는
사실은 Visual Studio C++에서 유닛 테스트 플랫폼이 굉장히 좋아졌고
굉장히 짜기 쉬우니까 한 번쯤 해보라는 말을 하고 싶었지만 그 뒤에 덧붙여서 다른 얘기도 했네요.
포프였습니다.