취미 게임에 테스트가 1000개 넘는다고요? 낭비일까요?

우리 프로젝트에는 이제 천 개가 훨씬 넘는 자동화 테스트가 있어요. 서버 쪽에 약 990개, Unity 클라이언트에 약 120개예요. 가족 프로젝트에는 과한 것처럼 들려요. 사실은 정반대예요. 이유를 말해 줄게요.

테스트는 우리의 두 번째 개발자예요. 혼자 하는 프로젝트에는 코드 리뷰에서 “잠깐, 그러면 제작이 망가지잖아” 하고 말해 줄 사람이 없어요. 테스트가 바로 그 동료예요. 레시피, 산소, 배고픔, 생물 행동, 월드 비밀번호 같은 모든 게임 규칙에 변경할 때마다 도는 테스트가 있어요. 두려움 없이 리팩터링할 수 있는 게 진짜 이득이에요.

짜증 나지 않을 만큼 빨라요. 15분 걸리는 테스트는 아무도 돌리지 않아요. 그래서 CI 관문이 두 단계예요. 풀 리퀘스트 검사는 빠른 테스트로 3분 남짓에 끝나고, 느린 전체 테스트는 그 뒤에 돌아요. 그러면 커버리지를 잃지 않고도 개발 루프가 경쾌하게 유지돼요.

Unity 테스트는 그 자체로 하나의 주제예요. 실행 중인 엔진 안에서는 클라이언트 로직을 테스트하기 어려워요. 우리의 요령은 이래요. 클라이언트의 핵심 로직은 Unity 없이 돌아가는 별도 라이브러리에 두고, 평범한 코드처럼 헤드리스로 테스트해요. 정말로 엔진이 필요한 것만 EditMode/PlayMode 테스트로 돌려요.

경고는 오류예요. 우리 CI는 “warnaserror”로 빌드해요. 컴파일러 경고 하나하나가 빌드를 깨요. 까다롭게 들리지만, 중요한 경고 하나가 결국 묻혀 버리는 경고 무덤을 막아 줘요.

솔직한 결론이에요. 테스트를 쓰는 데는 개발 시간의 아마 5분의 1이 들어요. 하지만 고친 기능은 모두 계속 고쳐진 채로 있어요. 그리고 퇴근 후 저녁에 살아나는 프로젝트에게는, 주말에 만든 기능이 화요일 기능을 망가뜨리지 않았다는 확신보다 더 값진 건 없어요.