Unity - 데이터 관리 함수의 유닛테스트 회고 요약
인게임 데이터함수에도 테스트 유닛을 적용해 보았다.
얼마 전 게임 내부 함수에 접근할 수 있는 권한이 생겼다 (야호) 해서 내친김에, 여기에도 유닛테스트를 붙여보기로 했다.
UI에서와는 다르게, 내부함수에서는 "붙여놓은 테스트가 불의의 사건으로 인해 깨지거나 잘못된 값을 테스트할" 가능성을 비교적 덜(!)해도 된다. 아닌게 아니라, 함수는 변경될 하이라키나 코드 외부에서 여러가지 이유로 변화할 수도 있는 임의로 지정된 이름들이 없으니까!
다시 말해 UI테스트에서는 "유사한 대상들 사이에서 원하는 타겟을 딱 잡아낼 수 있지만. 너무 한정적이어서 타겟의 상태가 조금이라도 바뀌는 순간 타겟을 잃어버리는 정도는 아닌" 상태의 조건을 계속 고민해야 했지만. 일반 함수의 기능을 테스트하는 상황에서는 그런 고민에서 좀 더 자유롭다는 이야기이다.
내가 이번에 구현하게 된 기능은
- 레벨업 가능한 N개의 슬롯이 존재하고,
- 두번째 슬롯부터는 이전 슬롯을 X만큼 강화해야 해금되며.
- 강화에는 각 슬롯마다 정해진 재화가 레벨별로 지정된 양만큼 들어가야 하고.
- 시도 전 시도 가능 여부를 미리 알 수 있어야 한다..
등의 조건을 가지고 있었다.
테스트하기 용이한 포맷으로, 기능을 구현할까?? 생각했지만. 이미 유사한 기능이 존재하고 있어서. 해당 기능의 포맷을 맞춰서 작성하는게 맞다고 생각했다(즉 테스트적으로 더 완벽한 상황을 만드는 것 보다. 기존 구조와의 일관성을 유지하는 쪽을 선택했다).
기존의 구조를 복제하고, 달라지는 부분을 구현한 뒤, 테스트를 붙였는데. 테스트를 붙일 때 테스트 유닛 별 독립성을 보장하기 위해, 기능의 상태를 초기화하는 함수를 추가해 퍼블릭으로 빼 두었다. 구동 -> 준비 -> 테스트 -> 종료가 가장 이상적인 상태겠지만.. TestRunner에서 제공하는 플레이 테스트의 경우 구동 -> 종료까지 4초 넘게 소요되어서. 이상적인 상태를 고집하면 "테스트는 빠르게 자주 시행할 수 있어야 한다" 원칙에 위배된다고 생각했기 때문에 매 시행 전 초기화함수를 실행하는 것으로 타협했다.
테스트 케이스는
- 슬롯 값 리턴 여부 체크,
- 불가능한 배열 인덱스 접근,
- 각 슬롯마다 재화가 없을 때,
- 재화가 약간 모자랄 때
- 재화가 충분할 때
- 0레벨부터 MAX까지 강화시도,
- 각 슬롯 별 레벨구간 별 다음슬롯 잠금여부 확인
등을 만들어두었다.
확실히 그냥 코드를 짜서 배포하는 것 보다, 테스트를 붙여놓는 쪽이 든든하고 좋다.
사족이지만 현재는 테스트를 시행할 때 테스트의 대상이 되는 국소적 영역만 유저데이터를 초가화하고 있는데. 게임 특성상 유저데이터에 여러 경우의 수가 존재할 수 있기 때문에.. 해당 경우의 수들을 교체해가면서 테스트를 시행해볼 수 있는 방법을 고민 중이다.
'DevLog' 카테고리의 다른 글
Unity - Playfab Event Log 붙이기 회고 (0) | 2022.08.27 |
---|---|
일하고싶은 곳이라고 생각하는 기준 여섯가지 (0) | 2022.08.13 |
잘하는 개발자? (0) | 2022.08.09 |
Unity - unit test 붙이기 회고 (0) | 2022.07.16 |
입사 6개월차 회고 (0) | 2022.07.13 |