[워밍업 클럽] BE 클린코드&테스트 4주차 발자국
강의 요약
Persistence Layer
Data Access의 역할
비지니스 가공 로직이 포함되어서는 안된다.
Data에 대한 CRUD에만 집중한 레이어
DataJpaTest
Jpa 관련된 Bean만 로딩한다.
상대적으로 빠름
기본적으로 @Transactional이 달려있다. → 자동으로 롤백
SpringBootTest
모든 Bean을 로딩한다.
상대적으로 느림
WebMvcTest
Controller 관련 Bean만 로딩한다.
상대적으로 빠름 </aside>
Business Layer
비지니스 로직을 구현하는 역할
Persistence Layer와의 상호작용(Data를 읽고 쓰는 행위)을 통해 비지니스 로직을 전개시킨다.
트랜잭션을 보장해야한다.
Presentation Layer
외부 세계의 요청을 가장 먼저 받는 계층
파라미터에 대한 최소한의 검증을 수행한다.
Test Double
https://martinfowler.com/articles/mocksArentStubs.html
Dummy
아무것도 하지 않는 깡통 객체
Fake
단순한 형태로 동일한 기능은 수행하나, 프로덕션에서 쓰기에는 부족한 객체
ex) FakeRepository
Stub
테스트에서 요청한 것에 대해 미리 준비한 결과를 제공하는 객체
그 외에는 응답하지 않는다.
상태 검증
Spy
Stub이면서 호출된 내용을 기록하여 보여줄 수 있는 객체
일부는 실제 객체처럼 동작시키고 일부만 Stubbing할 수 있다.
Mock
행위에 대한 기대를 명세하고, 그에 따라 동작하도록 만들어진 객체
행위 검증
미션 회고
3개의 테스트코드에서 중복된 내용을 @BeforeEach 로 합치는 미션.
단순히 중복을 없애는 것이 아니라, 각각의 테스트가 의미를 가지도록 묶어야 하는 미션이었습니다.
이 미션을 통해 Fixture를 생성할 때 Fixture의 생성에 초점이 맞춰지는 것이 아닌 테스트에 초점을 맞춰 문서의 기능을 할 수 있도록 해야한다는 것을 알았습니다.
@BeforeEach
void setUp() {
1-1. 2-1. 3-1. 사용자 생성에 필요한 내용 준비
1-2. 2-2. 3-2. 사용자 생성
1-3. 2-3. 3-5. 게시물 생성에 필요한 내용 준비
1-4. 2-4. 3-6. 게시물 생성
}
@DisplayName(""사용자가 댓글을 작성할 수 있다."")
@Test
void writeComment() {
// given
1-5. 댓글 생성에 필요한 내용 준비
// when
1-6. 댓글 생성
// then
검증
}
@DisplayName(""사용자가 댓글을 수정할 수 있다."")
@Test
void updateComment() {
// given
2-5. 댓글 생성에 필요한 내용 준비
2-6. 댓글 생성
// when
2-7. 댓글 수정
// then
검증
}
@DisplayName(""자신이 작성한 댓글이 아니면 수정할 수 없다."")
@Test
void cannotUpdateCommentWhenUserIsNotWriter() {
// given
3-3. 사용자2 생성에 필요한 내용 준비
3-4. 사용자2 생성
3-7. 사용자1의 댓글 생성에 필요한 내용 준비
3-8. 사용자1의 댓글 생성
// when
3-9. 사용자2가 사용자1의 댓글 수정 시도
// then
검증
}
느낀점
실무에서 테스트코드를 짤 때 했던 고민들이 많이 해소되어서 좋았습니다.
특히 어떤 테스트코드가 좋은지, 어떻게 작성하여야 문서로서의 기능을 할 수 있을지 알 수 있는 시간이었습니다.
답변 0