일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- OIDC
- AWS
- Batch
- fetch join
- Hibernate
- @Transaction(readOnly=true)
- N + 1
- 데드락
- Cannotacquirelockexception
- 성능테스트
- JPA
- @controller
- 정적 팩터리 메서드
- awspring
- spring-cloud-starter-aws
- Convention
- Cache
- @RequestMapping
- ngrinder
- mockito
- jdbc
- Git
- oauth2.0
- batch insert
- spring
- 이펙티브 자바
- 동시성
- injellij
- MySQLTransactionRollbackException
- assert
- Today
- Total
목록Test (2)
정리정리
doRetur와 thenReturn Mockito에는 stubbing을 하는 방법이 크게 2가지가 있습니다. 바로 doReturn/when 방식과 when/thenReturn 방식입니다. 두 방식 모두 거의 같은 기능을 제공하지만, 몇 가지 차이점이 존재합니다. 예시를 보면서 하나씩 알아보겠습니다. 1. void 메서드 Stubbing 많은 사람들이 stubbing을 할 때 when/thenReturn 방식을 사용한다고 합니다. 이 방식이 좀 더 사람이 읽기 쉽게 적혀있어서 선호된다고 하네요. 하지만 이 방식은 void 메서드를 stubbing 하지 못한다는 단점이 존재합니다. 그래서 이럴 경우에는 doReturn/when 방식에서는 doNothing()이라는 메서드를 지원하기 때문에 void 메서드의 ..
JPA는 특성상 실제 쿼리를 날리지 않아도 DB의 값이 변경되는 경우가 많습니다. 그리고 보통 영속성 컨택스트의 생명 주기가 서비스 계층과 비슷하기 때문에 서비스 계층 단위 테스트를 할 때는 JPA를 포함시켜 테스트를 많이 합니다. 특히 스프링의 @Transactional은 테스트 코드에 추가할 경우, 테스트가 끝나면 자동으로 트랜잭션을 롤백해주기 때문에 간단하게 JPA를 포함시켜 서비스 계층을 테스트할 수 있습니다. 하지만 그랬다가는 예상치 못하는 오류가 발생하는 경우가 있기 때문에 주의해야 합니다. 이번 포스팅에서는 서비스 계층 테스트 코드에 @Transactional을 붙였을 때 문제점과, @Transactional을 이용하지 않고 테스트 코드를 작성하는 방법에 대해 적으려고 합니다. Spring ..