서론
새로 프로젝트를 시작하면서 몇가지 정해놓은 목표가 있다.
CI / CD, Docker 등등 있는데 그 중 하나가 TDD였다.
지금까지 조금씩 사용하고 있었어서 그냥 하면되지라는 마인드로 시작했는데....
폭망했다 지금 시작한지 세네시간이 지났는데 테스트 케이스 하나를 못만들고 있다.
사실상 TDD가 어떤 개발론인지만 알뿐 아무것도 모르는 바보였다.
본론
이상태로 진행하기에는 의미가 없다고 생각해서 TDD 공부를 한 이후에 프로젝트를 진행하기로 했다.
시간이 여유롭지는 않지만 또 못할정도는 아니라고 생각해서...
기술 블로그를 통해서 얼추 공부하고 이후 관련 서적을 사서 공부할 예정이다.
먼저 기술 블로그를 보면서 공부하자
현재 진행하는 프로젝트는 짜잘한 로직과 json 관련 로직이 많기 때문에 해당 내용 위주로 먼저 공부할 예정이다.
일단 기본적인 이론만 정리하자. 진짜 심각하다고 느낀게 이것도 몰랐다.
TDD 사이클
- RED: 테스트를 작성한다. 뭘 개발할지 생각
- GREEN: 실행 가능한 코드를 만든다. 어떻게 통과시킬지 생각
- REFACTORING: 코드를 다듬는다. 개선 방향을 생각
- RED
- 실패하는 테스트 케이스를 작성한다.
- 무엇을 만들지, 어떤 기능을 구현할지 명확히 한다.
- 테스트는 최대한 작은 단위에 집중한다. (단위 테스트)
- GREEN
- 테스트가 통과하도록 최소하느이 코드를 작성한다.
- 구현의 완성도보다는 동작하는데 집중한다.
- REFACTORING
- 중복 제거, 가독성 향상, 구조 개선 등 코드를 다듬는다.
- 테스트가 깨지지 않도록 주의한다.
실무 장점
- 코드의 모듈화가 자연스럽게 이루어진다.
- 테스트 커버리지가 높아지기에 리팩토링과 유지보수가 쉬워진다.
- 프로젝트의 퀄리티가 높아지고 협업에 도움이 된다.
- 버그에 소요되는 시간을 줄일 수 있다.
- 이후 서비스 확장 및 추가에 용이하다.
여러 블로그를 보다가 느낀건데 뭔가 처음부터 잘못된 느낌이다. 지금 api를 받아오는 메서드를 위해 냅다 Controller에서 api를 받아오고 User를 저장하는 테스트를 구현하려고 하고 있었다.
그런데 생각해보니까 Repository -> Service -> Controller 순서로 테스트 코드를 작성하는게 맞는 것 같다.
그러면 지금 User api에서 사용하는 데이터들의 유효성 검사도 먼저 해야되는건가.
맞다고 생각한다. Repository -> Service -> 유효성 검사 -> Controller 순서로 가야되는 것 같다.
실제 서비스와 역순으로 흘러간다.
결론
최범균 저자의 '테스트 주도 개발 시작하기'와 로버트 C 마틴의 '클린 코드'를 사기로 했다. 책이 개발의 전부는 아니지만 읽고 사이트 프로젝트를 진행하면서 적용하면 좋은 개발 역량을 얻을 수 있다고 생각한다.
읽고난 후에 다시 정리해서 올려야겠다. 사실 TDD 자체가 중요한게 아니라 TDD를 왜 써야하고 어떤 점에서 좋은지를 정확하게 아는게 더 중요한 것 같다.
요즘 프로젝트를 진행하면서 생각없이 서비스 구현하고 배포하고가 끝이었는데 이제는 진중하게 공부하면서 할 필요가 있다는 것 같다. 열심히해야지
