보통 TDD(Test-driven development)는 잘 짜여진 테스팅 케이스를 이용해 소프트웨어의 수행 결과를 점검하는 형태로 이루어진다. 문제는, 이 방식의 접근은 처음부터 TDD를 하지 않으면 적용하기 힘들다는 거다!
게다가 최근 TDD가 없이는 개발이 불가능한 상황에 봉착했다. 입력 데이터의 종류는 수없이 많고, 이 데이터의 조합에 따라 서로 Side-effect를 발생시키는 골머리아픈 상황이다. (소프트웨어 설계가 잘못된건 아니다. 애시당초 풀어야할 문제가 이렇게 꼬여있다.) 설상가상으로 데이터의 종류가 무엇인지 알지 못하는 상황에서 종류를 guessing하고 조합해서 문제를 풀어야 할 정도니 말 다했다. 그리고, 출력되는 결과물도 굉장히 다양하다. (그 입력만큼이나 복잡하다)
프로게이머도 아닌데 엄청난 키보드+마우스 컨트롤을 자랑하며 테스팅을 할 수는 없는 노릇이고 해서, 간단한 테스팅 프로그램을 도입해서 문제를 해결하기로 생각하였다. 입력데이터를 잘 준비해두면 생성된 결과물을 잘 검사하기만 하면 되는 일 아니겠는가?
이 정도만 되면, 문제를 해결하기는 쉬울 것이지만 검사해야 할 항목들이 자주 변한다는 사실을 깨달았다. 입력데이터별로 차이도 존재하고, 데이터 종류에 따라, 또 그 조합에 따라 항목은 계속 바뀌어야 한다. 이쯤되면, 간단한 스크립트 언어를 만들어서 검사항목을 쉽게 변경할 수 있게 하면 되리라는 생각이 든다. 어머나. 배보다 배꼽이 커져버렸다. 🙂
그래서, XML과 XPath를 도입하기로 했다. 수행결과를 XML로 남기고, 남겨진 XML파일이 가져야할 조건, 즉 정상적인 생성물의 조건을 XPath 표현식으로 작성하는 것이다. TDD의 용어로 말하면, XPath 표현식은 Test case가 된다.
시험적으로 전체 시스템의 일부에만 적용해 보았는데 아주 마음에 든다. 물론, 서로 의존관계에 있는 XPath 표현식을 계층적으로 처리해주는 작업을 해야하긴 하지만, 그건 천천히 해도 될 것 같다. 🙂
ps. 관련된 코드와 예제를 공개하고 싶지만, 작업하다보니 대외비 코드가 너무 많이 들어갔네요. T_T
