🚀What I learend

지난 1주일간 진행했던 Mini-Project 에서 좀 더 개선할 수 있는 부분이 뭐가 있을지,
어떻게하면 좀 더 좋은 코드를 짤 수 있을지, 이번 프로젝트에서 부족했던 것이 무엇이었는지 고민했다.
고민의 결과는 Testing 이었다.
이번 프로젝트에선 내가 구현한 비지니스 로직에 대해 테스트하지 않았다. Postman을 이용하여 한 것도 테스트라면 테스트라고 생각할 수도 있지만, 내가 말하는 테스트는 Jest를 이용한 비지니스 로직 테스트다.

테스트를 하지 않는다면?

이번 Mini-Project 에서 초반에 구현한 코드와, 프로젝트를 진행하며 리펙토링하여 완성한 코드는 꽤나 달랐다. 리펙토링을 하며 이 코드가 맞는 코드인가를 검증하기 위해 많이 시간을 소요했다. 코드를 수정하고 매번 Postman 으로 Request를 날리며 정상적으로 동작하는지 확인했다. 굉장히 비합리전인 방법이었던 것 같다.

만약 내가 Jest 를 이용하여 테스트 코드를 작성했었더라면?

프로젝트 초반에 테스트 코드를 작성하여 모든 로직들이 Pass 했다면, 나는 나의 코드에 대해 자신감을 가지고 리펙토링을 할 수 있었을 것이다. 또한 테스트 결과를 보며 리펙토링을 하기에 개발 시간을 단축시켰을 것이고 단축한 시간동안 더 많은 것을 할 수 있었을 것 이다.

테스트란 무엇일까

내가 생각하는 테스트를 한문장으로 말한다면 "제품이 예상한 대로, 원하는 대로 동작하는지 확인하는 것이다.

테스트 했을 때의 장점은 뭐가 있을까
아래 나열한것과 같이 많은 장점이 있겠지만, 문서화와 자신감있는 리펙토링이 좋은 장점이라고 생각한다.
한가지 더 붙히면 재미이다. 테스트를 만족해가며 로직을 구현하는 재미를 한번 보니 코딩이 좀 더 재밌어진 것 같다.

• 기능이 정상 동작
• 요구사항 만족
• 이슈에 대해 예측
• 버그 조기 발견
• 손쉬운 유지 보수
• 코드 품질 향상
• 코드간 의존성을 낮춤
• 좋은 문서화
• 시간 절약
• 자신감 있는 리펙토링

Jest 를 이용한 테스트

Jest : https://jestjs.io/docs/getting-started

Jest 공식 사이트를 보며 기본적인 Jest 테스트 기법들을 공부했다.
Github : https://github.com/liamjeon/study-unittest-jest.git

비동기/동기 일 때의 테스트 방법, 그리고 Mock을 이용한 기본적인 코드들을 구현해 봤다.
우선 당장의 목표는 다음주에 있을 클론 프로젝트에서 TDD를 이용하여 로직을 구현하는 것이다.
그리고 이미 진행했던 mini-project 에서도 test 를 작성해야겠다.

테스트는 선택이 아닌 필수다.