9시 20분경 회사에 나왔다. 종희씨도 있었다. 항상 그러하듯 신문과 공병호씨 글을 조금 읽어보았다. 오늘은 잘 안 읽히는 듯 하다. 아침에 논문아이템에 대한 생각이 떠올랐다. TC의 무결성을 강화하는 방법에 대한 것이었다. 획기적인 방법을 제시할 단계는 아닌 듯 하다. 하지만 TC의 무결성을 보장하는 것은 어려운 일이고 사실 관련 과제를 수행해보지 않은 사람들은 미리 예측하고 대비하기가 어려울 수도 있을 것이다. 무결성을 보장하는 방법은 아래와 같이 제시할 수 있을 것이다.
1. TC를 검증하는 TC를 작성한다.
중요하고 복잡한 TC에 대해서는 필요할 수도 있을 것이다. 하지만 이 방법을 적용하면 또다른 TC를 구현해야 하는 비용적 문제가 발생을 한다. 그리고 새로 만든 TC의 무결성은 다시 어떻게 검증해야하는가 하는 문제도 생기게 될 것이다.
2. TC Spec.기반으로 TC Inspection을 행한다.
일반적인 방법이다. 하지만 TC를 유지/보수하는데 있어서 어려움을 야기할 수 있다. 개발코드가 변화하는 등의 이유로 TC도 계속적으로 변하게 된다. 이 경우 TC Spec.과 TC 코드간의 Sync를 항시 고려해야할 것이다. 그러나 사실 이것은 그리 쉬운 일이 아니다. 일례로 Spec.상에 기술된 한 문장이 실제 코드로 변환되면 수라인 혹은 수십라인이 될 수도 있다. 물론 한 문장이 한 라인으로 쓰여질 수도 있을 것이다. 때문에 이후에 임의의 TC개발자가 TC Spec.과 Code를 함께 볼 때에 Spec.의 각 라인이 코드상의 어떠한 부분을 커버하는지 확인하기가 어렵게 된다. 두가지 문서 혹은 파일을 동시에 보는 것도 불편할 것이다. 그리고 이는 결과적으로 유지/보수를 어렵게 만든다.
3. TC Code내부에 Spec.을 삽입한다.
제시하고자 하는 방법이다. 어쩌면 많은 주석으로 코드가 지저분해질 수도 있다. 하지만 Inspection에는 도움이 될 것으로 생각을 한다. Reviewer는 Spec.의 해당라인이 정확히 코드의 어떤 부분을 가리키는지 용이하게 확인할 수 있다. 또한 코드의 주석을 통해서 가독성이 향상된다. 그리고 주석상에 눈여겨 볼 사항들을 강조할 수 있고 이를 통해서 유사한 TC들을 보다 빠르게 검증하고 확인해 나아갈 수 있게 된다.
코드에 Spec.을 넣는 방법은 도구의 지원을 받을 수도 있다. 즉, excel, notepad 혹은 doxygen기반으로 spec을 작성하고 도구를 간단하게 수행하여 주석으로 구성된 슈도코드를 자동적으로 만들 수 있을 것이다.
그렇다면 왜 개발코드와 TC코드는 어떻게 다를까? 개발코드 검증은 크게 두 가지 방법으로 행해진다. 블랙박스 테스팅방법에서는 요구사양서를 기반으로 테스트가 진행된다. 화이트박스 테스트에서는 대표적인 것이 Inspection이다. Inspection은 기본설계서, 상세설계서 그리고 실제 코드를 기반으로 행해질 수 있다. 반면 TC코드의 무결성은 TC Spec.과 소스코드의 inspection에 크게 의존하게 된다.
오늘은 윤정씨와 준호선임의 결혼식이 있다. 그리고 정언씨 동생이 결혼을 하는 날일 듯하다. 결혼식에 가는 것이 항시 귀찮고 싫것만은 아니다. 가고 오면서 책을 읽을 수 있고 맛있고 때로는 고급스런 식사를 먹을 수 있기 때문이다. 그리고 가끔은 정장을 입어보는 것도 하나의 즐거운 일인 듯 하다.