TDD 시작

 

Better late than never. 

 

 

나의 과거의 개발 방식을 뒤돌아 보면 다음과 같다. 

 

1. 요구사항을 파악한다. 도메인 전문가 와 직접적인 대화를 통해 모든 요구사항을 듣고 분석하여 정리한다.

 

2. 서버의 아키텍처를 생각한다. 

 

3. 서비스 성격에 맞는 데이터베이스를 선택 및 설계를 한다.

 

4. 각 도메인에 필요한 부가 기능 및 외부 모듈을 검토한다.

 

5. 실제 비즈니스 로직을 작성한다.

 

이후 나는  요구사항대로 클래스를 만들고 인터페이스를 도출할 수 있는지 고민하고 필드의 타입을 고민하고 해당 클래스가 어떤 행위를 할지 생각하여 메서드를 만들어 기초적인 틀을 잡는다. 

 

이 과정은 어떤 부분은 문서화를 진행하고 어떤 부분은 머릿속에서 생각하면서 진행된다.  

 

이후 실제 코드를 작성한다. 기능 구현이 완료되었다면 테스트 서버에 배포 이후 동작을 검증한다. 

문제가 발생하면 디버깅을 통해 찾거나 논리가 잘못되었는지 검토한다. 

 

만약 코드를 작성하고 실제 테스트 서버에 적용하기 전까지 많은 코드를 작성했다면 시간은 곱절 이상으로 들어간다. 

아직도 테스트 코드를 작성하지 않고 테스트 서버에 올려 확인한다는 게 말이 안 되는 것처럼 보여도 해당 개발 분야의 시니어가 없거나 초보 개발자로만 구성되었고, 이들이 많은 프로젝트를 진행하고 있다면 많은 부분을 넘겨서 작업한다. 

 

그리고 오픈하면 개발자 입장에서 생각하지 못했던 버그들이 수없이 쏟아져 밤낮 고생하는 일이 비일비재하다. 

 

몸으로 눈으로 겪으면서 더 이상 그렇게 개발하고 싶지 않았다.  그렇게 테스트를 진행하고 싶지 않았다. 

 

최근 리팩터링과 클린 코드 책을 읽으면서 주목했던 부분이 있다. 

 

"테스트"

 

어찌 보면 당연하지만 그 당연한 것을 바쁘다는 핑계로 넘긴 사람들에게 강한 인상을 주는 내용이 담겨 있었다.

 

리팩터링 입장에서 테스트를 볼 때 기존 코드를 수정함에 따라 변경된 코드가 제대로 동작하는지 확인하는 기준에 대해 물어본다면 테스트 코드이다. 

 

잘 짜인 테스트 케이스는 리팩터링 된 코드에 대해 개발자의 불안감이나 예상하지 못하는 버그를 찾는 기초적인 틀이 될 것이다.

 

이는 결국 코드를 리팩터링 하고, 추가적인 기능을 구현할 때나, 클린 코드 원칙을 적용해 코드 구조를 바꾸는 경우 

이를 변경할 수 있는 시작점이 기존 코드에 대한 테스트 케이스라는 말이다. 

 

그의 말에 공감하면서도 한쪽으로는 불안하기도 했다. 

 

개발자에겐 주어진 시간이라는 것이 있다. 이 기간 안에 빠르게 개발하고 빠르게 배포하고 빠르게 피드백을 받는 것이 최선이라고 생각한다. 이를 위해 CI-CD를 구축하고 코드를 각 개발 분야 사람들과 협업하면서 빠르게 피드백하는 것이 요즘 추세가 아닌가 싶다. 

 

그런데 테스트 코드를 작성하는 일은 분명 시간이 소요된다. 

 

1. 테스트 코드도 유지보수 범주에 들어간다. 기존 코드가 크게 변경되었다면 테스트 코드도 반드시 변경되어야 한다. 

이 경우 놓치는 테스트 코드를 작성하게 되면 테스트코드가 있어도 버그를 발생시킬 수 있다. 따라서 들어가는 노력이 두배가 된다.

 

2. 테스트 코드를 작성하는데 있어서 공부를 해야하고 테스트코드 작성하는데 시간이 들지 않는가에 대한 걱정이다.

 

이와 관련해서 책을 보면서 조금 정리해보았다. 

 

테스트 코드가 없는 기존 프로젝트를 유지 보수할 때 버그가 발생했을 때 디버깅하는 시간과 개발할 때 테스트 코드를 작성하여 이후 유지보수 시 빠르게 처리할 수 있는 시간을 놓고 봤을 때 미래적으로 더욱 생산성이 뛰어날 것이라고 예상된다. 

 

전제는 애플리케이션이 유지 보수되지 않을 일은 없다. 추가 기능이 반영되지 않을 일은 없다. 왜냐하면 그런 애플리케이션이나 소프트웨어는 죽은 소프트웨어이기 때문이다. 

 

테스트 코드를 공부하는 진입 장벽은 사실 상 많은 테스트코드 작성 경험으로 부터 얻는 것이 가장 크고 개발자에게 공부라고 해봤자 코드를 작성하면서 배우는 일이기 때문에 책 한권과 적절한 프로젝트에 테스트코드를 작성하면서 배우면 

그 효과는 두 배로 빠르게 배울 수 있을 것이다. 

 

또한  TDD가 주목받으면서 다양한 테스트 케이스에 대해 많은 자료들이 존재하기에 오랜 시간을 소비하지 않을 것이라고 판단할 수 있다. 

 

다만 걱정되는 부분은 동료 개발자, 팀원들의 인식이다. 바쁜 게 프로젝트를 하는 팀원들에게 갑자기 테스트 코드를 적용하자라고 강제할 수는 없는 부분이다. 

 

이는 다음과 같이 해소하면 좋을 수 있을 것 같다. 

 

혼자 진행하는 프로젝트에 잘 짜인 테스트 케이스를 구축한다. 기능 요청 및 유지보수 시 매우 안정성 있고 빠르게 적용한다. 

그리고 회의시간이나 점심시간에 가볍게 주제를 던지고 장점을 설명하여 가스 라이팅을 한다.  DONE

얼마나 긍정적인 가스 라이팅인가.. 

 

결론은 

 

나도 이제 기존 프로젝트에 대해 테스트 케이스를 하나씩 만들어가고 이후 추가적인 기능에 대해선 TDD를 적용해서 개발해보겠다는 이야기고 테스트를 작성하는 방법 및 관련 라이브러리나 프레임워크, 애플리케이션 레이어 별 좋은 테스트 코드를 작성하는 방법과 테스트하기 좋은 코드를 만들기 위해 기존 코드를 리팩터링 하는 이러한 작업을 진행할 것이라는 것이다. 

 

과거 SI회사에서 보았던 단점들을 그대로 가져가고 싶지 않기에 좋은 개발자들이 있는 회사의 입장에서는 많이 늦은 개발자 일지 몰라도 빠르게 공부하고 적용하면서 나도 안정성 있는 테스트가 주는 개발 생산성을 느껴보고 싶다는 것이다.

 

 

Better late than never. 

 

 

-ps 

 

하 사실 tdd보다 ddd를 먼저 공부하고 싶긴하다