TDD의 가장 큰 약점으로 꼽히는 것은 바로 GUI 레이어에 대한 테스트가 어렵다는 것이다. GUI는 특성상 유저의 상호 작용을 필요로 하므로 일반적인 테스트 프로젝트처럼 싱글 스레드 기반의 구조적인 프로그래밍으로는 무리가 있다. 그래도 출력을 밀어넣기만 한다면 어찌저찌 되겠지만 출력 내용이 올바른지 검사해야 하거나 입력까지 필요로 한다면 테스트 시스템을 구축하는 비용이 훨씬 커져서 테스트 기반만 마련하다가 프로젝트가 끝날 판이다. (사실 어플리케이션 환경에 따라서는 그러고도 출력 내용을 검사할 수 없는 게 태반이다)
때문에 TDD 방법론에서는 대개 GUI 쪽 테스트 시스템 구축을 포기하거나 휴리스틱한(이라고 쓰고 수동이라고 읽는) 방법을 선택하는데 GUI 테스트가 많이 필요한 환경에서는 분명 솔루션의 부재가 아쉽다. (아예 없지는 않지만 사실 있다고 보기도 좀 프로그램에게 미안하다)
누리에서도 채팅 기능은 생각보다 복잡해서, 출력도 여러 가지를 요구하지만 입력 데이터도 다양하고 채팅의 종류도 다양하다. (마스터 채팅, NPC 채팅, 시스템 채팅, 주사위, 이미지 삽입, 링크, …) 채팅 내용 자체의 출력은 RichTextBox 등을 사용하면 그럭저럭 편하게 할 수 있지만 다음 화면과 같이 나오게 하기 위해서는 윈도우 컨트롤 중 가장 복잡한 ListView 컨트롤 + Owner Drawing의 조합이 필요하다.
커뮤니케이션 도구인 아틀라시안의 힙챗 중 일부
안타깝게도 TDD를 통해서는 저 내용이 제대로 출력되는지 확인하기가 요원하다. 아무리 단위 테스트Unit Test를 거치더라도 그것은 아래의 이미지에서 보듯이 반쪽짜리 테스트 밖에 되지 않는다.
단순하게 도식화된 채팅매니저, 테스트 코드, 실제 GUI 폼 간의 관계
사실 여기서 구조가 제대로 정비되려면 추가 정비가 필요한데 그것이 무엇인지 생각해보는 것도 괜찮을 것 같다.
