많은 si 개발자들은 테스트 코드를 작성하지 않는다.
테스트 코드의 필요성을 느끼지 못하기 때문이다. 서버 로직과 클라이언트 로직을 전부 구현하는 입장이다보니, 구지 서버단만 떼놓고 테스트를 해야 할 이유가 없다고 생각한다.
테스트 코드 작성할 시간에 화면을 만들지 않겠니. 는 많은 si 개발자들이 흔히들 하는 생각이다. 그렇다보니 개발 환경을 구성할 때를 제외하고는 거의 테스트 코드를 작성하지 않는게 현실이다.
물론 모든 si 환경이 그렇지는 않겠지만 상당수는 화면에서의 사용자 테스트만 갖는다.
테스트 코드가 필요한 사례 1.
- 서버 단에서만 2개의 api와 그 외에 여러 개의 모듈이 사용되었다.
- 클라이언트 단에서도 2개의 js api가 사용되었다.
- 서버 로직도, 클라이언트 로직도 둘 다 구현이 상당히 복잡하다. 구현하려면 각각 시간이 필요하다.
이런 경우에는 어떻게 해야 할까?
- 어떻게든 전부 완성해서 브라우저 화면에서 테스트를 진행한다. 서버 단의 오류와 클라이언트 단의 오류를 동시에 해결하는 유능함을 뽐내다가 개같이 멸망한다.
- 일단 api를 하나씩 적용할 때마다, 원하는 결과가 나오는지 로그로 찍어서 테스트한다. 그리고 야근한다.
- 일단 서버 단의 결과가 제대로 넘어오는지 클라이언트 단에서 디렉토리 로그로 찍어본다. 근데 로그가 나오기도 전에 js api에서 컴파일 오류 나는 꼴 보고 극대노 해서 마우스 부숴버린다.
- 서버는 서버, 프론트는 프론트로 나눈다. 서버 단의 로직이 제대로 실행하는지, 원하는 결과가 나오는지 사례 별로 테스트 코드를 작성하여 서버 로직부터 제대로 마무리 한다.
프로젝트를 하다보면 흔히 마주하는 상황이다. 게시판 같은 간단한 CRUD만으로 구성된 프로젝트는 없으니 말이다. 특히 결제 기능이나 회원 기능 등에서 흔히 겪을 수 있는 문제다.
서버 단과 클라이언트 단의 복잡한 로직을 동시에 처리하는 것은 불가능하다. 물리적으로 불가능하다. 더군다나 결제 기능 같은 크리티컬한 부분은 고려해야 할 사항들이 상당히 많다. 그렇기 때문에, 1층이 제대로 지어졌는지 확인 후에 2층을 올리듯, 단위 테스트 등을 실시하여 단계 별로 제대로 구현되었는지 짚고 넘어가야 한다. 거듭 말씀 드리지만 한 번에 여러 단계를 처리할 수는 없다.
단순히 서버와 클라이언트를 나누는 것뿐만 아니라, 영속 계층과 서비스 계층. 모듈과 MVC 계층을 나눠서도 생각해 볼 수 있다.
테스트 코드가 필요한 사례 2.
- 서버 단은 구현 한지 오래지만 모종의 이유로 클라이언트 단이 구현되지 않았다. (디자인이 미완성이던, 프론트 개발자가 구현을 못했던.)
- 내가 구현해야 할 파트는 끝났지만 다른 모듈이 아직 구현되지 않았다.
- 모종의 이유로 기능이 미완성된 상태로 당분간 놔두다가 나중에 다시 작업해야 하는 경우.
이런 경우에는 어떻게 해야 할까
- 한동안 방치해뒀다가 구현 과정 다 까먹고, 좀 더 자세히 주석을 달아놓지 않은 과거의 자신을 저주한다.
- 훗날, 동료 개발자가 당신이 만든 부분 적용하게 검토하고, 설명 좀 해달라고 한다. 근데 한참 전에 구현한 부분이라 뇌정지와서 어버버 거리다가 동료에게 쓰레기를 보는 듯한 시선으로 포상을 받는다.
- 기어코 오류가 나고, 동료 개발자와 니 책임, 내 책임 따지며 (나쁜 의미로) 극한의 오너쉽을 보여준다.
- 작성해뒀던 테스트 코드를 실행시키며 전체적인 로직을 재확인하고, 본인이 구현해놓은 부분이 정상적으로 작동하는 것을 확인하여 불필요한 소요를 줄인다.
테스트 코드는 특히 협업에서도 빛을 발한다. 과거에 작성한 코드가 언제, 어떤 상황에서, 어떻게 작동하는지 일일이 다 기억하고 있을 수는 없다.
그렇다고, 책임 소재를 따지기 위해 테스트 코드를 작성하는 것은 아니다. 본인이 작성한 코드가 어떤 결과를 내는지 동료들이 확인해야 하는 경우도 적지 않게 생긴다. 이 때 테스트 코드가 있다면 누구든 쉽게 코드의 작동을 확인해볼 수 있다.
본인을 위해서, 그리고 동료를 위해서 테스트 코드는 꼭 작성하자.
(하)편으로 이어집니다...
