요즘 테스트 코드의 필요성을 점점 느끼고 있다.
그런데 고민을 하다보면 코드의 일관성이 중요하다는 생각이 뚜렷해지고 있다.
예를 들어서, request, response 모델을 만들때 무조건 특정 방식으로 똑같이 찍어내듯이 짜야 한다는 것이다

왜 코드를 일관성 있게 짜야 할까? 우선 세가지를 들 수 있다.

1. 가독성: 같은 패턴으로 작성된 코드는 새로운 사람이 와도 빠르게 이해할 수 잇다.
2. 유지보수성: 규칙이 있으면 리팩토링이나 스펙 변경 때 특정 위치만 집중적으로 관찰할 수 있어서 사이드 이펙트가 줄어들 수 있다.
3. 테스트 용이성: 위에서 예시로 든 것처럼 request/response 모델이 동일한 규칙(Codable, naming 등등)으로 정의되어있으면 테스트 코드 구현 시에도 편하다.

예시로 Request/Response에서는 어떻게 일관성을 챙길 수 있을까?

• 네이밍 규칙: UserResponse 같은 접미사 통일
• 프로퍼티 매핑: response 추가 시, snake_case -> camel case를 항상 CodingKeys에서 처리
• Sample Data: Sourcery나 정적 확장을 이용해서 .sample 데이터 자동 생성
• 에러 처리: Response 실패 케이스를 통일된 규칙으로 감싸서 테스트 시 에러를 동일하게 핸들링

테스트를 예시로 들면

• Given-When-Then 구조 고정: 테스트 메서드마다 동일한 템플릿
• Mock / Stub 네이밍 규칙

그렇다면 항상 일관성을 챙겨야 하는가?
모든 것을 100% 템플릿처럼 찍어낸다면 오히려 유연해야 하는 상황에서 막힐 수 있다.
그래서

• 공통 레이어 (네트워크, 모델, 에러, 로깅 등)에서는 일관성을 가져야 하고,
• 도메인 별 뷰/로직에서는 어느 정도의 일관성만 챙겨도 되지 않을까?

즉, Request/Response/Repository 계층, Test 패턴 같은 인프라 코드는 찍어내듯이 짜도 될 것 같고 (물론 이것도 항상 100%는 아니지만..) 뷰나 유저 경험에 가까운 코드는 유연하게 짜면 된다고 생각한다.