안정적인 소프트웨어를 작성하는 데는 여러 가지 고민해야 될 사항이 있겠지만,
그 중 딱 2가지만 고르라고 한다면,
하나는 '설계'를 그리고 다른 하나는 'Unit test'를 고를 것 같습니다.
그 두 번째, 'Unit test'에 대한 이야기 입니다.
저의 첫 module을 작성을 하던 때였습니다.
온 정성을 다해서 코드를 작성했습니다.
'버그가 없는 완벽한 코드를 작성할 테다!'
'완성!' 드디어 Integration시험이 시작됩니다.
그런데, 믿고 있던 제 module에서 버그가 발견되는 것이 아니겠습니까?
'하나쯤이야.'
시간이 흐르면서 버그는 계속 발견되었습니다.
게다가 이전에 잘 동작하는 것들이, 수정 후에 잘 동작하지 않는 버그도 만들어 냈죠.
'이런~ 자존심 상합니다'
'API의 argument를 그런 식으로 사용한단 말이야?'
'초기화 이전에 그 API가 불릴 수도 있구나'
'그 API들을 동시에 사용한다 말이지?'
API는 경험이 부족했던 제가 예상하기 힘든 방법으로 사용되었고,
'설마?' 했던 것들도 시간이 지나면서 버그로 나타났죠.
그 때부터 '어떻게 하면 이런 버그들을 만들지 않을 수 있을까?' 라는 고민을 시작한 것 같습니다.
찾은 답이 바로 'Unit Test' 입니다.
'Unit test'란 별 것 아닙니다.
Module의 API를 상상할 수 있는 모든 방법으로 시험하여 버그 없음을 확인하는 것이죠.
예를 들어, Argument가 하나 있고 그 범위가 1..100 이라면,
1을 주면 동작하는가? 100을 주면 동작하는가?
0을 주면 실패하는가? 101을 주면 실패하는가?
이런 식으로 시험을 하는 것입니다.
제가 배운 Point는 2가지인데,
첫 번째는 시험 자체가 '자동'이어야 한다는 것입니다.
버그를 수정하게 되면 이런 걱정을 합니다.
'다른 부분에는 영향이 없는 건가?'
관련 없는 부분인 것 같은데, 잘 돌던 코드가 안 도는 경우가 생기게 됩니다.
이때, 자동 Unit Test가 있으면, 코드를 마음 편히 고칠 수가 있게 되는 거죠.
버튼만 누르면 '성공' 이 표시가 되니까요.
코딩이 다시 재미있어집니다.
그런데, 이렇게 시험을 해도 버그는 발견됩니다.
이유는 간단하죠. 경험이 부족하다 보니, 정작 시험해야 할 경우를 빼먹으니까요.
이것이 두 번째 point입니다.
Unit Test는 'Upgrade' 되어야 합니다.
생각하지 못했던 경우가 생기면, 이를 추가하는 겁니다.
Code와 더불어 Unit Test도 계속 Upgrade되는 거죠.
이렇게 계속 추가하다 보면, 언젠가는 완벽에 가까운 Case를 가지게 되겠죠. 하하
결국, Unit test의 목적은 간단합니다.
'한번 만든 버그를, 두번 다시 만들지 말자'
여기까지가 제가 찾은 간단한 방법입니다.
효과는 어땠냐고요?
다행히도 현재는 상당히 적은 수의 버그가 발견되고 있으며,
팀원들의 대부분은 제가 코딩을 잘 하는 것으로 오해를 하죠.
Unit test에서 발견되는 수많은 버그를 모르니까요.
근데, 하나 좋지 않은 것도 있습니다.
코딩이 약간은 재미 없어진다는 거죠.
Module coding이 100 이라면
Unit test coding을 40~70 정도 하게 되니까요.
설계의 고통처럼,
코딩의 고통은 Unit test작성이 아닐까 합니다.
고맙습니다.
