인프런에서 테스트 코드 관련 강의를 듣고 '테스트가 이런것이구나' 를 간접적으로 체험했지만 직접적인 체험을 원했던 저는, 현재 진행중인 프로젝트의 일부 도메인에 테스트를 적용 해봤습니다.
기존의 개발방식
백엔드에서 DB 로직을 작성하고, 서비스 로직, 컨트롤러 로직 순으로 작성하고 나면 하나의 API가 만들어집니다.
DB -> 서비스 -> 컨트롤러 => API 완성!
위와 같이 한번에 원큐로 완성되면 정말 좋겠지만, 저같은 경우는 그렇지 않더군요.
DB -> 서비스(어라? 파라미터 뭔가 모자른데?) -> DB -> 서비스 -> 컨트롤러(파라미터 또 모자란다..) -> 서비스 ...(반복)
테스트를 도입한 개발방식
DB 테스트 작성 -> DB 로직 작성 -> 서비스 테스트 작성 -> 서비스 로직 작성 -> 컨트롤러 테스트 작성 -> 컨트롤러 로직 작성
본 로직을 작성하기 전에 테스트(단위 및 통합) 코드를 작성하는 패턴으로 개발했습니다.
테스트는 또 아래 3단계를 거치곤 합니다
- Red: 빨간불을 뜨게 하라. 테스트 작성 전, 어떤걸 개발할 것인지 생각하는 단계
- Green: 초록불을 뜨게하라. 어떻게 개발할 것인지 생각하고 작성하는 단계
- Refactor: 개선하라. 작성한 코드를 개선하는 단계
테스트를 도입한 개발방식에서는 효과적인 테스트 코드를 작성하기 위해서 로직에 대해 다시한번 생각하게 됩니다. 그래서 기존의 개발방식과는 다르게 실수를 많이 줄일 수 있었죠.
테스트의 장점
테스트를 작성하는건 코드를 작성하는데에 실수를 바로잡는 역할을 하기도 합니다. 또한, 언급은 안했지만 전체적인 테스트 코드를 실행하고 나면, 혹여나 변경된 로직으로 영향을 끼친 코드가 있는지 테스트 코드로 확인할 수 있는 장점이 있습니다.
테스트의 단점
테스트를 도입한 개발방식이 기존 개발방식보다 시간적으로 더 느릴수도 있습니다.
위에서 봤던 테스트를 도입한 개발방식에서는 비즈니스 로직을 작성하기 전에 테스트를 먼저 작성하는 TDD 방식을 따랐습니다. 테스트를 추가적으로 작성해준다는 것 자체가 시간을 더 쓰게 만들수도 있는것이죠.
어떤상황에서 테스트를 추천 혹은 비추천 할까요?
추천: 프로젝트의 문서화 작성, 유지보수가 편한 프로젝트를 위함
비추천: MVP를 만들어야 하는 프로젝트, 빠른 시간안에 완료해야 하는 프로젝트
마무리
이렇게 '테스트 코드를 작성하면서 느낀점'을 간략히 작성해봤습니다. 감사합니다.
