여전히 많은 si 개발자들은 테스트 코드를 작성하지 않는다.
여전히 테스트 코드의 필요성을 느끼지 못하기 때문이다. 물론 모든 si가 그렇지는 않지만, 소프트웨어 자체보다는 프로젝트 갯수와 인력 머릿수가 상품인 si 시장이다보니 빠른 개발을 위해 테스트 코드를 포기하는 경우가 많다.
근데 테스트 코드를 작성하지 않는 것이 과연 더 빠른 개발을 할 수 있을까?
- 로컬에서 테스트가 끝난 프로젝트를 실제 서버에 배포할 예정이다.
- 로컬과 실제 서버는 웹 서버 구성부터 시작해서 다소 다른 부분이 많다.
- 실제 서버에 배포했을 때, 오류가 발생하면 즉시 NG.
이런 경우에는 어떻게 해야 할까?
테스트 코드에 처음 입문하는 사람들이 흔히 하는 오해가 있다. 테스트 코드가 단순히 본인이 방금 작성한 소스가 제대로 작동되는지를 확인하는 용도라고 생각하는 경우가 있다.
테스트 코드는 한 번 작성해놓으면 두고두고 쓰게된다. 테스트 코드의 목적은 '언제든', '어디서든', '누구나' 소스가 제대로 작동되는지 확인하기 위함이다.
테스트 코드가 필요한 사례 2번이 '언제든' 소스의 작동을 확인해본 사례라면, 이번 사례는 '어디서든' 소스가 제대로 작동하는지 확인하는 사례이다. 개발 환경과 운영 환경은 서로 다를 수밖에 없다.
DB의 다중화, 암호화, SSL 인증서, 클러스터링, 웹 서버의 유무, OS의 차이 등등, 단순히 개발만 하는 로컬 환경과 실제 운영 환경이 다를 수 있는 요소는 무궁무진하다.
하다 못해 같은 프로젝트를 진행하는 개발자들의 로컬 컴퓨터도 환경은 전부 미묘하게 다르다.
그리고 프로젝트는 어떤 환경에서든 정상적으로 작동되는지 확인할 수 있는 수단이 필요하다. 그때 이용될 수 있는게 테스트 코드이다.
- 다른 개발자 동료가 내가 작성한 소스를 업데이트 받은 상태.
- 동료가 내가 만든 소스의 오류 여부를 실시간으로 확인해보고 싶다고 한다.
- 본인이 만든 모듈이랑 연동되는 건데, 두 모듈이 같이 오류 나면 진짜 답 없다고.
동료와는 사이좋게 지내자.
작성된 소스는 프로젝트에 참여한 개발자라면 누구든 그 실행 여부를 확인해볼 수 있어야한다. 언제든, 어디서든, 누구나 중에서 누구나에 해당되는 부분이다.
여러개의 모듈이 서로 얽히게 되면 어디서 오류가 나는지는 중요한 문제다. 여러명이 만든 모듈을 한 사람이 전부 커버할 수도 없을 뿐더러, 어느 모듈에서 오류가 나는지를 찾는 것도 어렵다.
당신이 작성한 소스는 생각보다 많은 사람들이 사용할 수도 있다. 특히 공통 모듈을 작업했다면 프로젝트에 참여한 거의 모든 개발자들이 당신의 소스를 사용하게 될 것이다.
동료들에게는 당신의 소스가 굉장히 낯설 뿐더러, 자세한 로직도 모른다.
테스트 코드가 없다면 로직이 추가될 때마다, 서버 환경이 바뀔 때마다, 개발자가 바뀔 때마다 직접 화면을 키고 모든 버튼을 눌러보면서 기능을 확인해봐야 할 것이다.
한번이라도 개발을 해본 사람이라면 이게 얼마나 끔찍한 짓인지 알 것이다.
여러번 강조하지만 테스트 코드는 언제든, 어디서든, 누구나 코드의 작동 상태를 확인하기 위해 존재하는 것이다.
테스트 코드는 수동 테스트의 부담을 줄여주는 도구이다. 테스트 코드를 작성하는 시간이 아깝다고? 일일이 손으로 테스트 해야 하는 비용이 훨씬 크고 길고 지루하고 끔찍하다.