다른 팀원에게 공유할겸 테스트 코드 작성 방법에 대해 작성해보려고 한다.
테스트 코드 작성 방법을 들어가기에 앞서 먼저 테스트 코드 작성을 왜 작성해야 하는지 내가 느꼈던 테스트 코드가 필요한 이유를 나열해보려고 한다.
1차 스터디에서 구현한 9oorp.store version1은 이른 시간에 구현해야 했기 때문에 테스트 코드를 사용하지 않고 개발했다.
간단한 CRUD 구현했기 때문에 로직에 대한 확신이 있었지만, 점점 늘어나는 요구사항과 협업하면서 다른 팀원이 작성한 코드, 시간이 지나면서 내가 작성한 코드를 잊어버리는 등 코드에 대한 확신이 떨어지면서 코드에 대한 신뢰도가 감소했다.
이런 일들이 반복되어 코드에 대한 신뢰가 점점 떨어지면 결국 프로젝트에 대한 의욕이 사라진다.
개인 프로젝트를 하면서 의욕이 없어진 프로젝트는 끝까지 마무리하지 못하거나 빨리 끝내고 싶어 대충 봉합해버리곤 했다.
마지막까지 프로젝트를 잘 마무리하고 싶다면 조금 귀찮더라도 미리 테스트 코드를 작성해서 프로젝트에 대한 신뢰도를 높이자!
처음 프로젝트를 진행하면서 모두 빨리 개발을 진행하고 싶어 해 개발 준비단계를 많이 뛰어넘어 버렸다. 특히 API 명세서를 URI만 정의하고 input, output을 넘겨버렸고, 주요 기능만 생각하고 나머지 기능들은 개발하면서 추가하는 식이었다.
이렇게 기획을 제대로 하지 않았더니 개발단계에서 커뮤니케이션문제가 매우 많이 발생했고 그에 따른 요구사항 수정 또한 많았다. (특히 API 명세서 쪽.. 이후 문서화의 중요성을 깨닫고 깃 북으로 API 명세서를 만들어 꼼꼼하게 작성했다.)
변경된 요구사항에 맞춰 코드를 하나씩 변경하다 보니 내가 작성한 코드도 읽기 힘들고 어색해 보여 코드 수정할 때마다 에러가 나지 않기를 기도했다.
만약 수정해야 할 코드에 테스트 코드가 잘 작성되어 있었다면 수정할 코드에 대한 로직을 빨리 파악할 수 있어 코드 수정을 안전하게 변경할 수 있었을 것이다.
기본적인 기능을 구현할 때나 사용자 입력에 대한 검증을 로직을 작성하면 내가 잘 구현했는지 확인을 해야 하는데 포스트맨으로 수동으로 테스트하니 너무 번거로웠다.
개발 → 스프링 실행 → 포스트맨으로 확인 → 에러 나면 스프링 종료, 코드 수정 후 반복 → 개발….
이런 노가다를 코드 수정할 때마다 반복했었다. 귀찮아서 뒤로 미루면 프론트엔드와 맞춰볼 때 더 큰 문제가 되어 찾아왔다.
테스트 코드를 잘 작성하면 노가다 수동 테스트에서 벗어나 빠른 피드백을 가질 수 있다!
이런 작은 프로젝트에도 테스트 코드에 대한 필요성을 느끼는데 실제 회사에 들어가면 얼마나 많은 테스트 코드가 있을까?
여러 서비스에서 개발자 채용 공고를 찾아본 결과 많은 회사에서 우대사항이나 자격요건에 테스트 코드에 대한 키워드를 많이 찾아볼 수 있다.
내가 프로젝트를 진행하면서 느낀 테스트 코드의 필요성뿐만 아니라 테스트 코드를 작성해야 하는 이유는 넘쳐나지만 이 정도면 나는 위의 4가지 이유만으로 테스트 코드를 작성해야 하는 이유는 충분하다고 생각했다.
지난 한 달 동안 개발한 프로젝트가 거의 마무리되어 여유 있을 때쯤 인프런의 Practical Testing: 실용적인 테스트 가이드를 보고 spring 테스트 코드에 관해 공부한 내용 정리 겸 포스팅한다.
이 포스트는 Practical Testing: 실용적인 테스트 가이드 강의를 참고하여 작성했습니다.