Practical Testing: 실용적인 테스트 가이드 강의를 수강하고 작성한 회고입니다.

1. 학습한 내용 및 회고

• 통합 테스트 (Integration Test)

  • 여러 모듈이 협력하는 기능을 통합적으로 검증하는 테스트

• 라이브러리와 프레임워크의 차이

  • 라이브러리는 외부에서 가져와서 내 코드에 쓰인다. 즉, 내 코드가 주체가 된다.

  • 프레임워크는 이미 갖춰진 환경이 주워지며, 내 코드가 수동적으로 프레임워크 안으로 들어가게 된다.

• Persistenc Layer 테스트에서는 데이터에 대한 CRUD 작업의 테스트를 진행하기 때문에 비즈니스 로직이 들어가서는 안 된다.

• Business Layer 테스트는 비즈니스 로직을 테스트하며, 트랜잭션을 보장해야 한다.

• @Transactional이 테스트 코드에만 있으면 문제가 될 수 있음을 뒤늦게 발견할 수 있기 때문에 주의해야 한다.

• Presentation Layer 테스트는 Controller 테스트로, 파라미터에 대한 최소한의 검증을 한다.

• 그리고 Presentation Layer 테스트를 할 때, Business Layer와 Persistence Layer는 Mocking을 해서 테스트를 진행한다.

• @Transactional을 쓸 때 Command와 Query를 분리하자.

  • Command

    • 상태를 변경하는 작업(CUD)을 한다.

    • 메서드 단위로 @Transactional(readOnley 기본값 false) 필요

  • Query

    • 상태를 조회하는 작업(R)을 한다.

    • @Transactional(readOnly = true) 필요

  •  변경 작업(Command)은 데이터의 무결성을 위해 쓰기 트랜잭션이 필요하고, 조회 작업(Query)은 성능을 위해 읽기 전용 트랜잭션이 적합하기 때문인다.

회고

부끄러운 이야기이지만 지금까지 @Transactional을 쓰면서 그냥 다 필요한 거 아닌가? 하면서 트랜잭션을 거는 조건을 생각하지 않은 채 사용했었다. 실제로는 트랜잭션의 성격과 사용 목적에 따라 명확하게 구분해야 하고, Command와 Query를 나누는 설계 자체가 데이터 무결성과 성능 모두에 영향을 미친다는 것을 알게 되었다.

이제는 습관적으로 @Transactional을 붙이는 게 아니라, '어떤 목적으로 트랜잭션이 필요한가?'를 먼저 생각하고 적용할 수 있도록 노력해야겠다.

그리고 'Spring과 Spring Boot 모두 프레임워크라고 불리는데 이 둘의 차이는 뭘까'라는 궁금증이 생겨 찾아봤다.

Spring은 애플리케이션의 핵심 기능(예: 웹, 데이터 접근, 보안 등)을 개발할 수 있도록 다양한 모듈과 기능을 제공하는 프레임워크이고, Spring Boot는 이러한 Spring의 여러 기능을 더 쉽고 빠르게 설정하고 실행할 수 있도록 도와주는 프레임워크이다.그래서 이 둘의 역할은 다르지만, 개발자가 정해진 구조 안에 코드를 작성하고 실행하게 만든다는 점에서 둘 다 프레임워크라고 할 수 있다고 한다.

2. 단위 테스트 코드 작성 미션 회고

 프로젝트는 스터디 카페 프로젝트로 선택했고, StudyCafePassType, StudyCafeSeatPass, StudyCafePassOrder의 단위 테스트를 작성했다.

작은 단위부터 테스트를 하기 위해 StudyCafePassType, StudyCafeSeatPass, StudyCafePassOrder 순서대로 진행했다.

StudyCafePassTypeTest에서는 도메인 규칙을 테스트하기 위해 StudyCafePassType.FIXED가 사물함 사용이 가능한 타입인지 테스트했고,

StudyCafeSeatPassTest에서는 비즈니스 조건을 테스트하기 위해 고정석 이용권이 사물한 이용 가능 조건인지, 시간 단위 이용권은 사물함을 이용할 수 없는지, 사물함 이용권과 좌석 이용권의 타입과 기간이 같은지, 할인율에 따라 할인 금액이 올바르게 계산되는지 테스트했다.

StudyCafePassOrder에서는 결제 금액 계산 로직이 정확하게 작동하는지 테스트했다.

이번 미션을 통해서 단순히 코드가 잘 작동되는가를 확인하는 걸 넘어서, 도메인 규칙과 비즈니스 로직이 제대로 구현되었는지 테스트하는 수단이라는 걸 느낄 수 있었다. 

출처

Practical Testing: 실용적인 테스트 가이드