API, 서비스, 도메인 테스트 및 TDD 에서의 기어비

API, 서비스, 도메인 테스트 및 TDD 에서의 기어비

테스트 필요 이유

테스트가 있으면 시스템 변경에 두려움이 적어진다. 하지만, 너무 많은 테스트는 코드 변경마다 테스트 코드도 같이 변경되어야 하는 문제가 있다.
테스트의 목적은 코드 변경에서 시스템의 특성을 강제로 유지하기 위해서다.

API 테스트를 작성하면 도메인 모델을 변경할 때 테스트 코드 변경의 양을 줄일 수 있다.

테스트 종류에 따른 얻는 것

구분	API 테스트	서비스 테스트	도메인(모델) 테스트
피드백	적음	-	많음
변경 장벽	낮음	-	높음
테스트 영역	넓음	-	한정

도메인(모델) 테스트

• 코드와 더 밀접하게 연관되어 작업시 높은 피드백을 받을 수 있다.
• 테스트 코드를 통해서 도메인에 대한 이해도를 높일 수 있다.

API 테스트

• 더 높은 수준의 추상화를 사용하므로 세부 설계에 대한 피드백을 받을 수 없다.

높은 기어비와 낮은 기어비

• 새로운 기능이나 버그를 수정할 때는 도메인 모델의 변경이 생긴다면, 서비스 테스트를 작성하는게 좋다.
  예를 들어, add_stock(), cancel_order() 등 서비스 함수를 작성한다면 서비스 계층 테스트가 더 결합이 적은 테스트를 작성할 수 있다.
• 새로운 도메인이거나, 프로젝트의 경우에는 도메인 모델에 대한 도메인 테스트를 작성해서 테스트 결과를 통해서 더 나은 피드백을 얻고 더 명확하게 설명해주는 문서를 얻을 수 있다.
• 처음 자전거를 타면 기어를 저단에 두어야 쉽게 움직일 수 있고, 이후 빠르게 움직이면 높은 기어로 변경해서 효율적인 움직임을 가질 수 있다.
  나중에, 급경사나 장애물 등을 만난다면 기어를 낮추어서 진행해야 한다.

결론

1. 기능당 E2E 테스트는 하나씩 작성한다.

• API 기능들이 서로 연결되어 잘 작동하는지 확인에 목표

2. 테스트 작성의 대부분은 서비스 계층을 목표로 한다.

• 서비스 계층의 테스트는 커버리지, 실행 시간, 효율 측면에서 간극 사이를 절충할 수 있게 해준다.
• 각 테스트 단위는 한가지 기능을 목표로 하고 Edge 케이스를 다루고, 비지니스 로직의 인풋과 아웃풋을 모두 테스트하기에 적절하다.

3. 도메인 모델을 사용하는 핵심 테스트를 적게 작성하고 유지보수 한다.

• 도메인 테스트는 커버리지가 작고 변경에 깨지기 쉽지만, 피드백이 가장 크며 잘못된 변경을 쉽게 감지할 수 있다.

4. 오류 처리도 다루자.

• 각 기능의 Happy Case 테스트를 작성하고, 하나의 Edge Case 테스트를 작성하자.