개발일지 (12월 1주차 회고)

 

 

Overview

 

회사 내 관리자페이지를 완전히 새로 기획하여 만들게 되면서, 이전에 급하게 만드느라 추가하지 못했던 기능들과 검토할 기회조차 없었던 기능들을 추가하려고 노력했다. 그 중에 하나가 바로 프로그램을 TDD를 사용하여 작성하는 방식이었는데, 사용자의 잔고와 사내의 잔고가 오가는 일이라 (자세한 내용은 사내 규정상 밝힐 수가 없다.) 잘못된 로직의 코드가 들어가게 되면, 큰 피해가 생길수도 있기 때문에 테스트 코드의 중요성을 깨닫게 되었고, 같이 개발하는 팀원들에게 부분적으로 TDD를 도입하는 방식을 제안했었다.

 

 

 

TDD 도입의 현실적인 한계.

 

TDD는 단순히 프로그램을 작성하고, 그 작성한 코드가 제대로 돌아가는지를 테스트하는 테스트코드를 작성한다는 개념이 아니라는 것을 이해하였다. TDD는 일종의 Development Paradigm으로, 코드를 짠 뒤에 테스트 코드를 작성하는 방식이 아닌, 우선 내가 작성할 코드가 어떻게 동작해야 하는지에 대한 케이스들을 테스트코드로 먼저 작성한 다음에, 이 테스트 케이스를 모두 통과하는 코드를 작성함으로써, 최소한 내가 생각한 범위 내에서는 제대로 동작하는 코드를 작성하고자 하는 것이다.

 

복잡한 연산들이나, 직접 잔고에 접근하는 로직들의 경우 거의 서버에서 처리하기 때문에 사실 프론트에서는 정확히 값을 전달하고 보여주는 부분들이 제대로 작동하는지에 중점을 두면 되었지만, 앞단에서 가끔씩 복잡한 데이터 가공 연산들을 처리하는 경우들이 있었기 때문에 TDD로 코드를 작성하는 것이 분명한 이점이 있을 것이라 여겼다.

 

하지만 결과적으로, 프로그램 작성 전반에 걸친 TDD 방식의 접근은 잠시 접어두기로 했는데

1. TDD에 대해서 체계적으로 이해하고 있는 개발자가 사실상 없었다. (본인 포함)

2. 테스트코드를 작성하고 그 뒤에 코드를 작성하기에는 개발 기간이 너무 촉박했다. (모든 TDD 관련 저서에서 지적하는 점이기도 하다)

3. React Functional Component에 대한 Jest + Enzyme의 mocking 지원이 완전하지 못했다.

 

결국 복잡한 데이터 가공 연산들에 대해서만 부분적으로 테스트 코드를 작성하는 방식으로 기간내에 개발을 완료하였으며, 개인 토이 프로젝트나, 기간이 조금 넉넉한 다른 프로젝트들을 진행할 때에 TDD방식으로 개발하는 것을 고려해 보려고 한다.