유니티 테스트 러너(Unity Test Runner)

 최근 클린 코드, 클린 코더라는 책을 읽으면서 TDD에 대한 의지가 생겼다. 두 책 모두 유닛 테스트의 중요성에 대해 많은 지면을 할애하여 설명하고 있었다. 그렇지 않아도 진행하던 개인 프로젝트의 규모가 점점 커져가고 있어 복잡도가 높아지고 있어 좋은 기회라는 생각이 들었다.

 

 유니티는 Unity Test Runner라는 이름으로 자체 유닛 테스트를 지원하고 있었다. 공식 문서를 살펴보니 유닛 테스트는 EditMode와 PlayMode의 두 가지 종류가 있다. EditMode는 본래 내가 생각하던 유닛 테스트의 개념으로 생각하면 될 것 같았다. 그에 반해 PlayMode는 테스트를 실행하는 경우 우선 Play상태가 되고, 코루틴을 지원하는 등의 유니티 특화 사양의 유닛 테스트로 이해했다.

 

 TDD를 진행해본적이 없기에 감은 없지만, 느낌적으로는 PlayMode 테스트를 최대한 줄이고 EditMode에서 수행되는 테스트가 많아지도록 짜는 것이 좋아보인다. 우선 PlayMode는 Play상태에 한 번 들어갔다 와야하기 때문에, 테스트에 대한 부하를 최소한으로 유지하는 것을 목표로 한다면 최소화 할 것 같다. 특히 내가 만들고 있는 게임은 2D 게임이기 때문에 PlayMode를 많이 사용할 것 같진 않다.

 

---

 

 Window > General > Test Runner를 클릭하면 Unity Test Runner창을 열 수 있다. 

 테스트 스크립트를 작성하기 위해선 테스트 스크립트 폴더를 만들어주고, 해당 폴더에 테스트용 유니티 어셈블리를 만들어주어야 한다. 그리고 우클릭 후 Test Script를 생성하면 기본 코드가 들어있는 코드가 자동 생성된다.

 

 그렇지만 막상 테스트 코드에서 원래의 게임 코드를 사용하려하면 해당 클래스를 찾지 못하는 것을 볼 수 있다. 아까 우리가 테스트 스크립트를 위한 별도의 어셈블리를 만들었기 때문인데, 해당 어셈블리에서 본래의 게임 어셈블리를 참조해주어야 한다.

 게임 스크립트가 들어있는 폴더를 포함하는 어셈블리를 만들어준 뒤에, 테스트 어셈블리에서 해당 어셈블리를 참조시켜주면 사용할 수 있다.

 

 여담이지만, 처음엔 어셈블리가 단 하나의 폴더만을 포함할 수 밖에 없는 줄 알고 스크립트가 포함된 폴더마다 어셈블리를 만들었다. 그렇게 하니 당연히 어셈블리가 얽히고 또 순환 참조 되고... 난리가 났다. 그런데 그 과정을 겪으면서 꽤 깨달은 것이 있다. 어셈블리들이 서로 물고 물리는 것을 보면서 내 코드들의 종속성들을 직접 확인했고, 아무렇지 않게 써놓은 코드들의 문제들을 다시 확인하게 되었다.

 예를 들면 인터페이스 클래스를 모두 모아놓은 폴더를 InterfaceAssembly로 만들어놓고, 다른 곳에서 이 어셈블리를 참조하게 하려했다. 그런데 왠 걸, 인터페이스가 콘크리트 클래스를 참조하고 있었다. 종속성의 계층 구조가 있어야한다는 것을 깨달았고, 언제라도 어셈블리가 분리되어도 괜찮도록 신경써가면서 짜고 있다.

 

 하여간 어셈블리를 잘 연결해주면 테스트 코드에서 우리 게임의 코드를 사용할 수 있다.

 EditMode에서는 Assert를 이용하여 테스트 결과를 체크할 수 있다. 테스트 코드를 작성하고 나면 Test Runner창에 테스트가 하나 추가된다. Run을 누르면 해당 테스트를 실행할 수 있고, 성공하는 것을 확인할 수 있다.

 

 PlayMode는 많이 써본 뒤에 추가로 작성해야지.

 많은 TDD관련 문서나 영상을 보면, 코드를 작성하기 전에 테스트를 먼저 작성하는 것을 권하고 있다.

 

 테스트 작성 -> 컴파일 실패 -> 컴파일 해결 -> 테스트 실패 -> 테스트 통과 -> 다시 테스트 작성

 

 요런 사이클로 코드를 작성하라는 것이다. 아직 어색하고, 어떻게 테스트 코드를 써야할지 감이 안오지만 계속 유닛 테스트를 작성해볼 예정이다.