[웹 자동차 경주] 배운 것 정리

1. 스프링 테스트에서 Junit5는 의존성 관리를 해주지 않는다.

스프링 테스트 시 @Autowired 어노테이션이 없으면, 의존성 주입을 해주지 않는다.

프로덕션 코드에서는 생성자 주입 시 @Autowired 어노테이션이 없어도 자동으로 스프링이 주입을 해줬다.

따라서, 테스트 코드에서도 생성자 주입 사용 시 @Autowired 어노테이션이 없어도 자동으로 주입될 줄 알았다.

 

하지만, 테스트 환경에서는 생성자 주입 시 스프링 IoC 컨테이너에서 스프링 빈을 찾는 것이 아니라,

생성자 매개변수 관리를 Jupiter가 하기 때문에

Jupiter에게 생성자 매개변수 관리를 처리할 ParameterResolver에게 요청을 보낸다.

하지만 해당 빈은 스프링 IoC 컨테이너가 가지고 있기 때문에 찾지 못해 에러를 발생시킨다.

 

이때, @Autowired 어노테이션이 있으면 Jupiter가 빈 주입을 스프링 IoC 컨테이너에게 요청하게 되어서

정상적으로 의존성 주입이 된다.

 

따라서, @Autowired를 붙이자!

---

2. Layered Architecture

Layered Architecture를 배우고 정리하였다.

https://ksh-coding.tistory.com/92

[아키텍쳐] Layered Architecture란? (feat. 자동차 경주 미션 예시)

---

3. Service와 Repository 계층의 필요성, 만든 이유?

https://ksh-coding.tistory.com/93

[아키텍쳐] Service, Repository가 왜 필요할까?

---

4. @SpringBootTest의 @Transactional과 TestDB

이번 미션에서 @SpringBootTest의 webEnvironment 속성으로 RANDOM_PORT를 줘야 했다.

... 이후 블로그 정리

---

5. gradle 의존성 키워드

크게 api와 implementation의 차이를 배웠다.

 

api : modulB에서 moduleA를 가져올 때 moduleA가 의존하는 라이브러리까지 가져온다.

implementation : moduleB에서 moduleA를 가져올 때 moduleA가 의존하는 라이브러리는 moduleA에 캡슐화되어 moduleA만 가져온다.

 

이러한 이유 때문에 모듈 간 의존성을 줄이려면 api보다는 implementation 키워드를 사용하는 것이 좋다!

(api로 가져오면 세부 사항까지 가져오고, implementation은 캡슐화된 moduleA만 가져오기 때문에)

 

이외의 키워드들은 시점 관련 키워드들이었다.

• runtimeOnly : 런타임 시점에 해당 라이브러리가 필요할 때 사용 
• testImplementation : 테스트 코드 실행 시에만 라이브러리를 사용

---

6. DTO 안에 변환 로직이 있어도 되는가?

처음에는 Mapper를 사용해서 DTO에 초기화 로직과 getter만 존재하도록 했다.

 

이렇게 하니, 변환이 필요한 DTO가 생성될 때마다 Mapper가 필요했다.

처음에는 단순히 데이터 전달 계층으로만 DTO를 생각했는데 응집도와 관리의 편의성 때문에

데이터를 전달하기 위한 변환 로직을 가져도 된다고 생각이 바뀌었다.

 

Mapper 클래스를 생성하는 비용보다, DTO 자체에 변환 로직을 작성하는 비용이 적다고 느꼈기 때문이다.

---

7-1. Repository가 Dao와 다른 점

크게 요약하면 Repository는 ‘도메인’을 다루고, Dao는 ‘DB’를 다룬다.

 

Repository는 Service 계층에서 도메인을 받아서 Dao에게 Dto, Entity로 전달하는 역할을 하고

Dao에서 전달받은 Dto, Entity를 도메인으로 변환하여 Service에게 전달하는 역할을 한다.

그래서 Repository는 도메인을 직접적으로 다루고,

Dao는 DB에 작업을 수행하는 DB단 계층이라는 점이 다르다.

 

7-2. Repository가 Service와 다른 점

Repository와 Service는 모두 ‘도메인’을 다룬다.

Repository는 도메인 자체의 CRUD를 다루고

(Service에서 전달받은 자동차 도메인을 DB에 저장)

Service는 이를 활용하여 비즈니스 로직을 수행한다.

(Repository에서 전달받은 자동차 도메인을 통해 ‘자동차 이력 조회’ 비즈니스 로직 수행)

---

8. 통합 테스트 VS 슬라이스 테스트 간단 요약

통합 테스트 : @SpringBootTest

• 계층이나 다른 객체와의 동작을 테스트
• 모든 스프링 빈을 테스트 시에 가져옴
• 테스트 속도가 느려서 빠른 피드백을 받을 수 없다.

 

슬라이스 테스트 : @JdbcTest, @WebMvcTest 등등

• 하나의 계층을 빠르게 테스트하는 테스트
• 테스트할 계층과 관련된 스프링 빈만 가져옴
• 테스트 속도가 통합 테스트보다 빠르다

 

리뷰어님의 팀에서는 통합 테스트가 테스트를 실행하는 시간이 길고,

세팅해줘야 할 것이 많아서 잘 하지 않는다고 한다.

대신 슬라이스 테스트를 꼼꼼하게 작성하신다고 한다!

---