원티드 프리온보딩 백엔드 - 1주차 과제 (2)

첫 번째 과제에서 내가 맡은 업무는 테스트케이스 작성이었다. 

테스트코드를 작성해 본적이 있냐, 하면 있긴 있다. Do it 시리즈 중에 '장고 + 부스트스랩' 책이 있는데,

이 책에서 테스트 코드를 작성하는 부분이 있어서 책 보면서 따라쳐 본 경험은 있다. 

 

내가 직접 케이스를 생각해보고 테스트 코드를 작성해 본 적은 없어서, 이번 과제에서 테스트 케이스를 맡게 되어서 좋았다. 

( 이번 과제는 테스트 할 api도 1개 이다. 😆)

 

장고에 내장되어 있는 unittest 모듈을 이용해서 테스트 케이스를 작성했다. 

책을 보면서 구성을 참고하긴 했는데, 책에서는 오리지널 장고로 개발한 기능들을 테스트 했고, 우리 과제는 DRF로 개발한 기능들을 테스트 해야 했기 때문에 이 부분에서 조금 어려웠다. 

DRF는 서비스 로직이 시리얼라이저에서 돌아가는 구성이기 때문에, 시리얼라이저를 위한 테스트 파일과 뷰를 위한 테스트 파일을 분리 했다.

시리얼라이저 테스트 파일에서는, 시리얼라이저를 통해 원하는 데이터만, 원하는 형태로 잘 직렬화 되는지를 테스트했고, 

뷰 테스트 파일에서는 api의 url이 우리가 작성한 view와 잘 맵핑이 되어있는지와 view에서 원하는 데이터들을 잘 반환 하는지를 테스트 했다. 

 

나는 테스트 케이스 작성을 api 개발이 끝나고 하는 것이라고 생각했다.

물론 이렇게 하는 방법도 있긴 하지만, 흔히 말하는 TDD란, api를 개발하기 전에 최소한의 테스트를 통해 우리가 구상한 로직이 잘 작동하는지 확인을 하고 api 개발을 들어가는 방식이라고 한다. 

'어떤 요청을 받고 어떤 응답을 하는지 모르는데 어떻게 테스트를 하지?' 라는 생각이 들었는데, 이것에 대한 의문은 마지막 주차 세션에서 해결이 되었다. 

 

실무에서는 api 개발을 위한 요구 명세서를 굉장히 상세하고 정확하게( 우리 과제처럼 해석의 여지가 다양하게 있지 않게 ) 주어진다고 한다. 요청할 때 어떤 인자가 필요한지( 혹은 필수인자들이 있는지 등), 응답은 어떤 데이터들이 와야하는지 상세하게 나와있기 때문에, 최소한의 로직을 구상해 놓고, 그렇게 구상한 로직이 요구 명세서에 일치하게 작동하는지 테스트를 통해 확인한다고 한다. 

 

과제를 할 당시에는 TDD에 대해 잘 몰랐기 때문에, api 개발 업무를 맡은 팀원과 미리 로직에 대해 함께 논의를 하고 테스트 케이스 작성을 했어야 한다는 아쉬움이 남았다. 

---

프로젝트 회고 🤔

처음으로 팀장을 맡은 조직에서 처음으로 하는 프로젝트라 굉장히 부담이 컸다. 

나는 팀장이 회의를 주도적으로 이끌고, 의견을 내고, 방향을 정해야 한다고 생각했기 때문에 더욱 그랬던것 같다.

그런데 너무나 감사하게도, 팀원분들 모두 적극적으로 의견을 내고 모두가 주도적으로 회의를 진행해 나가서, 사실 나는 한게 아무것도 없었다. 😅 

첫 프로젝트를 하면서 내가 팀장으로서 어떻게 임해야 할지 기준을 잡을 수 있었던 것 같다 .

 

프로젝트 하면서 아쉬웠던 점이 몇 가지 있었다. 

우선 비대면으로, 음성 채팅을 통해 회의를 하다보니까 내가 흐름을 잘 못따라가고 삽질을 많이 했던것 같다. 

회의하면서 문서 작성을 하긴 하는데, 각자 개인이 생각한 과제 분석 내용만 적어 놓고, 그 내용을 바탕으로 협의해 나가는 과정을 기록하지 않았더니 이런 어려움이 있었던 것 같다.

그래서 다음 과제를 할 때는 회의 내용을 상세하게 기록하는 작업이 필요하다고 느꼈다. 

 

두 번째로는, 우리가 컨벤션을 정하긴 했지만, 여전히 일치하지 않는 코드 스타일이 있다는 점 이었다. 

str을 표현할 때, 누구는 ' 를 사용하고 누구는 " 를 사용하기도 하고, 여러 클래스들을 작성할 때나 docstring을 작성할 때 몇 줄을 띄우는지 등이 일치하지 않아서 코드이 일관성이 아직은 부족하다고 느껴졌다. 

팀원들 모두 같은 생각이었고, 그래서 이 부분에 대한 추가적인 논의를 하기로 했다. 

 

이번 과제를 하면서 팀원들에게 정말 많이 배운것 같다. 

나는 내가 할 수 있는 선에서만 문제를 해결하려는 경향이 있었다. 그래서 이번 과제도 굉장히 단편적으로 바라보고 쉬운 길로만 과제를 수행하려고 했었다. 

그런데 이번에 팀원들과 함께 회의하면서 많이 반성했다. 

기본적인 요구사항을 충족시키는 것도 물론 중요하지만, 언제나 확장성을 고려해서 설계를 해야하고, 문제를 해결하기 위한 최선의 방법들을 모두 생각해본 후 주어진 시간과 리소스에 따라 방법을 정해야 한다는걸 배웠다.