나는 할일 관리 프로그램으로 ‘Things 3’ 를 쓰고 있다. 하지만 나에게는 할일 목록으로 등록하여 쓸 만큼 다채로운 할 일이 많다고 생각하지 않았다. 업무는 Jira 태스크 위주로 처리하고 나면 개인의 할 일이라는게 별게 없어 보였기 때문이다. 하지만 아니었다.
하루동안 뭘 하긴 한 것 같은데 그닥 남은게 없거나 생산적으로 보내지 못했다고 느낄 때가 많았다. 단순히 할일 관리 프로그램을 쓰는 방법이 문제가 아니고 나 자신의 생산성을 관리하는 체계 자체가 무너졌던 것이다. (아니면 그런 체계가 아예 없었을지도 모른다)
그래서 다른 사람들은 이 프로그램을 어떻게 쓰는지 살펴보고, 여기서 힌트를 얻어보자는 생각을 했다. 그러다가 꽤 괜찮은 글을 발견했다. 자신을 믿고 “목적에 따른 생산성 확보” 를 기반으로 하여 어떻게 생산성을 관리하는 ‘프레임워크’ 를 형성해나가는지 안내하는 글이었다. 제목과 같이 사용하는 도구가 Things이긴 하지만, 실제로 어떤 도구라도 이 글에서 제시된 대로 활용할 수 있다고 보기 때문에 좋은 글이라고 생각하고 있다.
아래의 항목들이 주요 내용이었고, 글이 조금 길긴 하지만 최대한 핵심적인 부분만 읽어나가면 자신만의 생산성 관리 프레임워크를 형성하는데 도움이 되리라 생각한다.
MIT에서 제공하는 자료이며 CS의 고급스런 주제를 학부에서 배울 수 있지만, 실제로 실무 개발을 하는데 유용한 내용을 가르쳐주는 것으로 보인다.
“우리는 이 수업을 통해 여러분들 들어봤을 법한 도구를 활용하는 방법을 가르치고, 쓸만한 도구들을 소개하고, 당신이 스스로 더 많은 도구를 탐구하고(무언가를 만들거나!) 관심을 가지길 바랍니다. 이 지식들은 통상적인 컴퓨터 공학 수업에서는 다루지 않을 내용일 것입니다.”
“(테스트를 하는데) 무엇이 중헌디” 가 결국 이 글에서 이야기하고자 하는 내용이라 생각한다. 내부 구현을 직접적으로 테스트하는 것을 피해야 하고 왜 그렇게 해야하는지 설명한다.
TC(테스트 케이스)는 바뀔 수 있는 모듈의 구체적인 것에 의존하면 안된다. 추상화된 것에 의존해야 한다.
그럼에도 불구하고 내부 구현이 테스트되어야 한다고 생각되는 모듈이 있다면, 해당 내부 구현이 독립된 책임을 갖는 별도의 모듈로 추출되어야 할 수도 있다는 뜻이다.
유용한(비용 효율적인) TC는 현재를 위해 TC를 작성하되 개발이 진행되면서 미래를 위한 TC로 바뀔 수 있는 것들이다.
테스트 자동화를 도입했다면 모듈과 마찬가지로 TC도 지속적으로 개선하고 리팩토링해야 한다. TC는 모듈을 테스트하는 모듈이다. 우리가 구현한 모듈과 아주 큰 차이는 없다.
내부 구현을 TC가 직접적으로 테스트하기보다 공개된 인터페이스를 이용하여 테스트하는 것을 권장한다. 물론 내부 구현을 직접 테스트하는게 더 쉬울 수 있지만, 정말 내부 구현을 테스트하여 커버리지를 올리는게 우리가 달성하고자 하는 목표인가? 아니면 공개된 인터페이스가 정상적으로 잘 동작하여 사용자가 사용을 하는데 이상이 없게 하는게 목표인가?
정말 ’도움이 되는 테스트’여야만 도움이 되는 것이다. ‘도움이 될 것 같은’ 테스트는 오히려 독이 될 수도 있다.