항해 플러스 백엔드 1주차 WIL - TFD(Test First Development)

TFD 미션 링크

GitHub - pbg0205/hhplus-tdd-java: hplus tdd 미션

 

 

[1] 왜 항해 플러스에 선택하게 되었는가?

 여러 사람과 개발을 하며 가장 중요하다고 생각이 들었던 것은 설득의 중요성이었다. 내 코드를 설득하기 위한 명확한 이유와 근거도 필요하지만, 내 생각과 기준을 다른 사람에게 설득하는 연습을 하기 위해서 참여하게 되었다.

 

[2] TDD 는 왜 필요할까? 그리고, TDD에서 중요한 것은?

테스트는 마치 보증서이자 설명서와 같다. 테스트는 기능이 의도한 대로 동작함을 보장할 뿐 아니라, 동작 방식을 설명하는 문서 역할을 한다. 이를 통해 비즈니스 로직을 더 쉽게 이해하고 유지보수할 수 있다. 테스트를 기반으로 비즈니스 로직을 작성하는 것이 바람직하다고 생각한다.

 

TDD는 명확한 요구사항 정의, 신뢰성과 유지보수성 향상, 그리고 문서화와 협업 지원의 이점을 제공한다. 테스트를 통해 요구사항을 구체화하고 문제를 사전에 발견할 수 있으며, 기능 안정성을 보장해 리팩토링과 추가 개발을 용이하게 한다. 또한, 테스트는 코드 동작 방식을 설명하는 문서 역할을 해 팀의 협업과 비즈니스 로직 이해를 돕는다.

 

이번 미션에서는 원활한 테스트 작성을 위해 행동 분석(유스케이스)와 테스트 케이스를 작성하는데 중점을 두었다. 내가 생각하는 TDD(Test Driven Development) 의 중요한 요소는 문서화이다. 명확한 요구사항 정리와 테스트 케이스 작성은 비즈니스 로직을 구체화하는 데 중요한 역할을 한다. 이 과정에서 예상하지 못했던 부분들을 확인할 수 있었고, 이를 통해 의도한 비즈니스 로직을 더 정확하고 효과적으로 구현할 수 있었다.

행동 분석

단위 테스트 케이스

 

 

 

시퀀스 다이어그램도 작성하였다. 비록 비즈니스 로직의 복잡도가 높지 않았지만 로직의 흐름을 한눈에 파악할 수 있고, 복잡한 문제를 단순화하여 이해 관계자와의 의사 소통을 원활히 할 수 있는 장점이 있어 앞으로도 더욱 활용해보아야겠다.

유저 포인트 API 시퀀스 다이어그램

 

[3] 작업 과정에서 겪었던 내용들

(1) 같은 CustomException 인데 다른 ErrorType 을 사용하는 경우에는 ErrorType 을 확인하자.

Business Layer 코드에서 같은 커스텀 예외를 반환하지만 에러 타입이 다른 경우에 예외 클래스만 검증하여  비즈니스 로직을 잘못 작성했었다. 이와 같은 실수를 줄이기 위해 Business Layer 에서 예외 클래스와 ErrorCode 검증하도록 구성하고 ErrorCode 를 문서화하여 정리해야겠다.

extracting, satisfies 를 이용해 확인

 

(2) ErrorType 은 common 에 두면 안될수도?

 기본의 ErorType 에 관한 정의를 common.api 하위 클래스로 배치했다. API 의 예외처리를 할 때 전달할 예외 코드와 메시지가 담겨있어 해당 위치에 배치했다. 그런데 이 예외는 결국 비즈니스 영역에서 발생한 예외이기 때문에 해당 도메인 패키지의 하위에 위치해도 괜찮은 방법일지도 모른다는 생각이 들어서 이후에 아키텍처 미션에서 더 고민해볼만한 요소인 것 같다.

 

 

(3) Context Caching 으로 인한 동시성 테스트 실패

따로는 되는데 같이는 안되는 테스트;

 

동시성 테스트를 위해 @SpringBootTest 기반으로 테스트하는 과정에서 테스트가 실패하는 이슈가 있었다. 원인은 spring context caching 으로 인한 이슈로 파악된다. 스프링은 TestContext 에서 context configuration 의 조합을 키로 하여 컨텍스트를 캐싱해 재사용하여 통합 테스트의 로딩 속도를 개선한다. 하지만, 캐싱은 단점 또한 존재한다. 빈 내부 데이터가 남아 있다면 다른 데이터에 영향을 미칠 수 있다. 즉, 포인트 소비 동시성 제어 테스트에 사용된 데이터가 포인트 충전 동시성 제어 테스트에 영향을 미쳐 테스트가 실패할 수 있다. context caching 의 키 조합은 아래의 요소들을 조합한다.

 

출처 : https://docs.spring.io/spring-framework/reference/testing/testcontext-framework/ctx-management/caching.html

 

가장 좋은 방법은 컨텍스트 캐싱을 사용하면서 빈이 관리하는 멤버 필드에 존재하는 데이터를 제거 또는 초기화해 테스트 고립성을 보장하는 것이다. 하지만 이번 미션에서는 클래스의 수정을 금지 되어 있어 불가피하게 @DirtiesContext 를 사용해 ContextCaching 된 값을 제거했다.