구직 과정에 코딩 시험이 있었다. 면접관의 컴퓨터와 응사자의 컴퓨터가 코딩 시험 도구로 연결되어 면접관이 응시자의 코딩을 지켜보거나 개입할 수 있는 환경이었다. 어떤 문제의 답 코드를 쓰다 10줄 이상이 되니 자신감이 떨어져 TDD를 사용하기로 했다. 여기서 나는 흥미로운 경험을 했다.

물론 코딩 시험에 테스팅 도구는 주어지지 않았다. TDD는 테스팅 도구가 있어야만 할 수 있는 것이 아니다.

이 글에서 테스트 케이스는 테스트 코드가 아니라 테스트 데이터를 의미한다.

나는 시험 문제를 반영한 간단한 테스트 함수를 만들고 제시된 테스트 케이스와 몇가지 임의의 테스트 케이스를 추가했다. 답 코드를 쓰는 과정에서 지속적으로 테스트를 실행했고 모든 테스트 케이스가 성공한 후 면접관에게 코딩이 끝났다고 말했다.

즉시 면접관 중 한 명이 버그가 있으니 수정해 달라고 얘기했다. 나는 버그를 찾기 위해 무의식적으로 답 코드가 아니라 시험 문제 지문과 테스트 케이스 목록을 확인했다. 잠깐 살펴봤지만 안타깝게도 나는 버그를 발견하지 못했다. 면접관에게 버그를 찾지 못했다고 말하자 면접관은 버그를 설명하는 대신 테스트 케이스 하나를 추가했다. 나는 추가된 테스트 케이스가 실패하는 것을 확인한 후 답 코드에 논리 하나를 추가했다. 다시 테스트를 실행했고 모든 테스트 케이스에 대해 성공 표시가 출력됐다.

이것이 나에게 흥미로운 이유는 코딩 시험 과정이 소프트웨어를 만드는 한가지 유용한 프로세스 사례의 축소판이 되었기 때문이다. 프로그래머는 구현 코드가 아니라 요구사항과 요구사항의 구체적인 사례에 더 집중한다. 도메인 전문가나 품질 책임자는 발견된 버그를 재현 방법과 함께 프로그래머에 전달한다. 프로그래머는 버그를 반복 재현하며 코드를 고친다. 작업의 완료와 소프트웨어 회귀(software regression)가 없음은 자동화된 테스팅을 통해 확인한다.

항상 코딩 시험의 평가자 역할을 수행하다 정말 오랜만에 응시자가 되었는데 이런 놀라운 경험을 하게 될 것이라고는 전혀 생각하지 못했다. 처음부터 버그 없는 답을 썼어도 좋았겠지만 나는 원래 완벽한 코드를 쓸 수 있는 사람이 아니다. 오히려 이번 경험이 앞으로 나에게 큰 영향을 줄 것으로 생각된다.