[스프링 DB 2편] #3. 데이터 접근 기술 - 테스트 #553

YuDeokRin · 2024-12-07T01:46:38Z

YuDeokRin
Dec 7, 2024
Maintainer

데이터 접근 기술 - 테스트

1️⃣ 테스트 - 데이터베이스 연동

실제 데이터베이스에 접근해서 데이터를 저장하고 조회할 수 있는 테스트를 알아보자

✅ 환경 설정

main에 application.properties 설정

spring.profiles.active=local
spring.datasource.url=jdbc:h2:tcp://localhost/~/test
spring.datasource.username=sa

logging.level.org.springframework.jdbc=debug

test에 application.properties 설정
- 테스트 케이스는 src/test에 있기때문에 실행하면 우선순위를 test에 있는 properties를 반영한다.

spring.profiles.active=test

하지만 테스트용 설정에는 spring.datasource.url과 같은 데이터베이스 연결 설정이 없다는 점이다.

테스트 케이스에서도 데이터베이스에 접속할 수 있게 test의 application.properties를 다음과 같이 수정하자.

spring.profiles.active=test
spring.datasource.url=jdbc:h2:tcp://localhost/~/test
spring.datasource.username=sa

logging.level.org.springframework.jdbc=debug

✅ 테스트 실행 - 로컬 DB

ItemRepositoryTest 테스트 코드를 확인 (src/test 하위에 위치)

@SpringBootTest 어노테이션

@SpringBootApplication를 찾아서 설정으로 사용한다.

▶️ @SpringBootApplication

@Slf4j
//@Import(MemoryConfig.class)
//@Import(JdbcTemplateV1Config.class)
//@Import(JdbcTemplateV2Config.class)
@Import(JdbcTemplateV3Config.class)
@SpringBootApplication(scanBasePackages = "hello.itemservice.web")
public class ItemServiceApplication {}

@SpringBootApplication 설정이 과거에는 MemoeyConfig.class를 사용하다가 이제는 JdbcTemplateV3Config.class를 사용하도록 변경됨. 따라서 JdbcTemplate을 통해 실제 데이터베이스를 호출하게 된다.
MemoryItemRepository → JdbcTemplateItemRepositoryV3

▶️ 테스트 실행

ItemRepositoryTest 테스트 전체를 실행하자.

주의 ! - H2 데이터베이스 실행되어 있어야 한다.

▶️ 실행 결과

updateitem() : 성공
save() : 성공
findItems() : 실패
findItems()의 오류 내용

java.lang.AssertionError:
 Expecting actual:
   [Item(id=7, itemName=ItemTest, price=10000, quantity=10),
     Item(id=8, itemName=itemA, price=10000, quantity=10),
     Item(id=9, itemName=itemB, price=20000, quantity=20),
     Item(id=10, itemName=itemA, price=10000, quantity=10),

findItems() 코드를 확인해보면 상품을 3개 저장하고, 조회한다.

ItemRepositoryTest.findItems()

@Test
 void findItems() {
		//given
     Item item1 = new Item("itemA-1", 10000, 10);
     Item item2 = new Item("itemA-2", 20000, 20);
     Item item3 = new Item("itemB-1", 30000, 30);
     
     itemRepository.save(item1);
     itemRepository.save(item2);
     itemRepository.save(item3);
		
		 //여기서 3개 이상이 조회되는 문제가 발생
     test(null, null, item1, item2, item3);
}

결과적으로 테스트에서 저장한 3개의 데이터가 조회 되어야 하는데, 기대보다 더 많은 데이터가 조회되었다.

▶️ 실패 원인

TestDataInit은 프로필이 local일 때만 동작하는데, 테스트 케이스를 실행할 때는 프로필이 spring.profiles.active=test이기 때문에 초기화 데이터가 추가되지는 않는다.
문제는 DB에 과거에 서버를 실행하면서 저장했던 데이터가 보관되어 있기 때문이다.
이전 데이터가 현재 테스트에 영향을 주고 있다.

2️⃣ 테스트 - 데이터베이스 분리

로컬에서 사용하는 애플리케이션 서버와 테스트에서 같은 데이터베이스를 사용하고 있어서 테스트에서 문제가 발생한다.
문제를 해결하는 방법은 테스트와 메인 애플리케이션의 환경을 분리해야한다(격리성)

✅ 데이터 베이스 구분

▶️가장 간단한 방법
- H2 데이터베이스를 용도에 따라 2가지로 구분하면 된다.
- jdbc:h2:tcp://localhost/~/test local에서 접근하는 서버 전용 데이터베이스
- jdbc:h2:tcp://localhost/~/testcase test 케이스에서 사용하는 전용 데이터베이스
데이터베이스 파일 생성 방법
- 데이터베이스 서버를 종료하고 다시 실행한다.
- 사용자명은 sa 입력
- JDBC URL에 다음 입력,
- jdbc:h2:~/testcase (최초 한번)
- ~/testcase.mv.db 파일 생성 확인
- 이후부터는 jdbc:h2:tcp://localhost/~/testcase 이렇게 접속

✅ 테이블 생성하기

testcase 데이터베이스에도 item 테이블을 생성하자.

drop table if exists item CASCADE;
 create table item
 (
     id        bigint generated by default as identity,
     item_name varchar(10),
     price     integer,
     quantity  integer,
     primary key (id)
 );

접속 정보 변경
- 이제 접속 정보를 변경한다.
- main - application.properties는 그대로 유지
- test - application.properties만 변경

▶️ main - application.properties

src/main/resources/application.properties

spring.profiles.active=local
spring.datasource.url=jdbc:h2:tcp://localhost/~/test
spring.datasource.username=sa

▶️ test - application.properties

src/test/resources/application.properties

spring.profiles.active=test
spring.datasource.url=jdbc:h2:tcp://localhost/~/testcase
spring.datasource.username=sa

✅ 테스트에서 매우 중요한 원칙은 다음과 같다.

테스트는 다른 테스트와 격리해야 한다.
테스트는 반복해서 실행할 수 있어야 한다.

3️⃣ 테스트 - 데이터 롤백

✅ 트랜잭션과 롤백 전략

테스트가 끝나고 트랜잭션을 강제로 롤백해버리면 데이터가 원래대로 돌아가 테스트의 원칙을 지킬 수 있다.
예) 각각의 테스트 실행 직전에 트랜잭션을 시작하고, 각각의 테스트 실행 직후에 트랜잭션을 롤백해야 한다. 그래야 다음 테스트에 데이터로 인한 영향을 주지 않는다.

1. 트랜잭션 시작 
2. 테스트 A 실행 
3. 트랜잭션 롤백
-------------------------
4. 트랜잭션 시작
5. 테스트 B 실행
6. 트랜잭션 롤백

테스트는 각각의 테스트 실행 전 후로 동작하는 @BeforeEach , @AfterEach 라는 편리한 기능을 제공한다.

@SpringBootTest
class ItemRepositoryTest {
     @Autowired
     ItemRepository itemRepository;
			
		 //트랜잭션 관련 코드
		 @Autowired
		 PlatformTransactionManager transactionManager; TransactionStatus status;
     
     @BeforeEach
     void beforeEach() {
         //트랜잭션 시작
         status = transactionManager.getTransaction(new DefaultTransactionDefinition());
		 }
     
     @AfterEach
     void afterEach() {
		 
			 //MemoryItemRepository 의 경우 제한적으로 사용
			 if (itemRepository instanceof MemoryItemRepository) {
             ((MemoryItemRepository) itemRepository).clearStore();
       }
			 //트랜잭션 롤백
       transactionManager.rollback(status);
     }
	//...
}

트랜잭션 관리자는 PlatformTransactionManager를 주입 받아서 사용.
참고로 스프링 부트는 자동으로 적절한 트랜잭션 매니저를 스프링 빈으로 등록해준다.
@BeforeEach : 각각의 테스트 케이스를 실행하기 직전에 호출된다. 따라서 여기서 트랜잭션을 시작하면 된다. 각각의 테스트를 트랜잭션 범위 안에서 실행할 수 있다.
- transactionManager.getTransaction(new DefaultTransactionDefinition()) 로 트랜잭션을 시작한다.
@AfterEach : 각각의 테스트 케이스가 완료된 직후에 호출된다. 따라서 여기서 트랜잭션을 롤백하면 된다. 그러면 데이터를 트랜잭션 실행 전 상태로 복구할 수 있다.
- transactionManager.rollback(status)로 트랜잭션을 롤백한다.

✅ 테스트 실행 하기 전 사전 작업

모든 ITEM 데이터 삭제

delete from ITEM

데이터 정상 삭제되었는지 확인

select * from ITEM

4️⃣ 테스트 @transactional

스프링은 테스트 데이터 초기화를 위해 트랜잭션을 적용하고 롤백하는 방식을 @transactional 애노테이션 하나로 깔끔하게 해결해준다.
이전 테스트에서 트랜잭션과 롤백에 필요했던 코드를 주석하자

@SpringBootTest
class ItemRepositoryTest {
     @Autowired
     ItemRepository itemRepository;
			
		 //트랜잭션 관련 코드
		 /* 주석 처리 
		 @Autowired
		 PlatformTransactionManager transactionManager; TransactionStatus status;
     
     @BeforeEach
     void beforeEach() {
         //트랜잭션 시작
         status = transactionManager.getTransaction(new DefaultTransactionDefinition());
		 }
		 */
     
     @AfterEach
     void afterEach() {
		 
			 //MemoryItemRepository 의 경우 제한적으로 사용
			 if (itemRepository instanceof MemoryItemRepository) {
             ((MemoryItemRepository) itemRepository).clearStore();
       }
			 //트랜잭션 롤백
       transactionManager.rollback(status);
     }
	//...
}

✅ @transactional 추가

import org.springframework.transaction.annotation.Transactional;

@Transactional
@SpringBootTest
class ItemRepositoryTest {}

✅ 테스트 실행 하기 전 사전 작업

모든 ITEM 데이터 삭제

delete from ITEM

데이터 정상 삭제되었는지 확인

select * from ITEM

ItemRepositoryTest 실행 → 성공

✅ @transactional 원리

스프링이 제공하는 @Transactional 애노테이션은 로직이 성공적으로 수행되면 커밋하도록 동작한다.
그런데 @Transactional 애노테이션을 테스트에서 사용하면 아주 특별하게 동작한다.
@Transactional 이 테스트에 있으면 스프링은 테스트를 트랜잭션 안에서 실행하고, 테스트가 끝나면 트랜잭션을 자동으로 롤백시켜 버린다!
findItems()를 예시로 알아보기

✅ @transactional이 적용된 테스트 동작 방식

테스트에 @transactional 애노테이션이 테스트 메서드나 클래스에 있으면 먼저 트랜잭션을 시작한다.
테스트 로직을 실행한다. 테스트가 끝날 때 까지 모든 로직은 트랜잭션 안에서 수행된다.
1. 트랜잭션은 기본적으로 전파되기 때문에, 리포지토리에서 사용하는 JdbcTemplate도 같은 트랜잭션을 사용한다.
테스트 실행 중에 INSERT SQL을 사용해서 item1 , item2, item3 를 데이터베이스에 저장한다.
1. 물론 테스트가 리포지토리를 호출하고, 리포지토리는 JdbcTemplate을 사용해서 데이터를 저장한다.
검증을 위해서 SELECT SQL로 데이터를 조회한다. 여기서는 앞서 저장한 item1 , item2, item3 이조회되었다.
1. SELECT SQL도 같은 트랜잭션을 사용하기 때문에 저장한 데이터를 조회할 수 있다. 다른 트랜잭션에서는해당 데이터를 확인할 수 없다.
2. 여기서 assertThat() 으로 검증이 모두 끝난다.
@transactional 이 테스트에 있으면 테스트가 끝날때 트랜잭션을 강제로 롤백한다.
롤백에 의해 앞서 데이터베이스에 저장한 item1 , item2 , item3 의 데이터가 제거된다.

✅참고

테스트 케이스의 메서드나 클래스에 @transactional 을 직접 붙여서 사용할 때 만 이렇게 동작한다.
그리고 트랜잭션을 테스트에서 시작하기 때문에 서비스, 리포지토리에 있는 @transactional 도 테스트에서 시작한 트랜잭션에 참여한다. (이 부분은 뒤에 트랜잭션 전파에서 더 자세히 설명하겠다. 지금은 테스트에서 트랜잭션을 실행하면 테스트 실행이 종료될 때 까지 테스트가 실행하는 모든 코드가 같은 트랜잭션 범위에 들어간다고 이해하면 된다. 같은 범위라는 뜻은 쉽게 이야기해서 같은 트랜잭션을 사용한다는 뜻이다. 그리고 같은 트랜잭션 을 사용한다는 것은 같은 커넥션을 사용한다는 뜻이기도 하다.)

5️⃣ 테스트 - 임베디드 모드 DB

테스트 케이스를 실행하기 위해서 별도의 데이터베이스를 설치하고 운영하는 것은 비용 측면에서 낭비이다.
단순히 테스트를 검증할 정도로만 사용하기 때문에 테스트가 끝나면 데이터베이스의 데이터를 모두 삭제해도된다.
더 나아가서 테스트가 끝나면 데이터베이스 자체를 제거해도 된다.

✅ 임베디드 모드

H2 데이터베이스는 자바로 개발되어 있고, JVM안에서 메모리 모드로 동작하는 특별한 기능을 제공한다.
그래서 애플리케이션을 실행할 때 H2 데이터베이스도 해당 JVM 메모리에 포함해서 함께 실행할 수 있다.
DB를 애플리케이션에 내장해서 함께 실행한다고 해서 임베디드 모드(Embedded mode)라 한다.

✅ 임베디드 모드 직접 사용

ItemServiceApplication - 추가

@Slf4j
//@Import(MemoryConfig.class)
//@Import(JdbcTemplateV1Config.class)
//@Import(JdbcTemplateV2Config.class)
@Import(JdbcTemplateV3Config.class)
@SpringBootApplication(scanBasePackages = "hello.itemservice.web")
public class ItemServiceApplication {

	public static void main(String[] args) {
		SpringApplication.run(ItemServiceApplication.class, args);
	}

	@Bean
	@Profile("local")
	public TestDataInit testDataInit(ItemRepository itemRepository) {
		return new TestDataInit(itemRepository);
	}

//----------------추가부분-------------------------
	@Bean
	@Profile("test")
	public DataSource dataSource() {
		log.info("메모리 데이터베이스 초기화");
		DriverManagerDataSource dataSource = new DriverManagerDataSource();

		dataSource.setDriverClassName("org.h2.Driver");
		dataSource.setUrl("jdbc:h2:mem:db;DB_CLOSE_DELAY=-1");
		dataSource.setUsername("sa");
		dataSource.setPassword("");
		
		return dataSource;
	}
//-----------------------------------------

}

위 코드 설명
- @Profile("test")
  - 프로필 test인 경우에만 데이터소스를 스프링 빈으로 등록한다. 즉 프로필 test여야지 dataSource()를 실행한다는 것
  - 테스트 케이스에서만 이 데이터소스를 스프링 빈으로 등록해서 사용하겠다는 뜻이다.
- dataSource()
  - jdbc:h2:mem:db - 데이터소스를 만들때 이렇게만 적으면 임베디드 모드(메모리모드)로 동작하는 H2 데이터베이스를 사용할 수 있음
  - DB_CLOSE_DELAY=-1 - 임베디드 모드에서는 데이터베이스 커넥션 연결이 모두 끊어지면 데이터베이스 도 종료되는데, 그것을 방지하는 설정이다.
위 코드 실행
- 테스트 실행 결과 → 실패
- Table "ITEM" not found → 오류의 핵심 메세지인데 데이터베이스 테이블이 없다는 것
- 메모리 DB에는 아직 테이블을 만들지 않았기 때문에 에러가 난다.

PreparedStatementCallback; bad SQL grammar []; nested exception is org.h2.jdbc.JdbcSQLSyntaxErrorException: Table "ITEM" not found; SQL statement:
INSERT INTO item () VALUES() [42102-200]
org.springframework.jdbc.BadSqlGrammarException: PreparedStatementCallback; bad SQL grammar []; nested exception is org.h2.jdbc.JdbcSQLSyntaxErrorException: Table "ITEM" not found; SQL statement:
INSERT INTO item () VALUES() [42102-200]

...

Caused by: org.h2.jdbc.JdbcSQLSyntaxErrorException: Table "ITEM" not found; SQL statement:
INSERT INTO item () VALUES() [42102-200]

✅ 스프링 부트 - 기능

기본 SQL 스크립트를 사용해서 데이터베이스를 초기화하는 기능
- 메모리 DB는 애플리케이션이 종료될 때 함께 사라진다. 그 이유로 애플리케이션 실행 시점에 데이터베이스 테이블도 생성해줘야 한다.
src/test/resources/schema.sql

drop table if exists item CASCADE;
 create table item
 (
     id        bigint generated by default as identity,
     item_name varchar(10),
     price     integer,
     quantity  integer,
     primary key (id)
 );

실행
- ItemRepositoryTest 를 실행해보면 드디어 테스트가 정상 수행되는 것을 확인할 수 있다.
로그 확인

#schema.sql
logging.level.org.springframework.jdbc=debug

6️⃣ 테스트 - 스프링 부트와 임베디드 모드

스프링부트가 앞서 배운것보다 더 쉽고 편리하게 만들어주는 임베디드 데이터베이스에 대한 설정을 제공한다.
ItemServiceApplication 주석 처리

@Slf4j
//@Import(MemoryConfig.class)
//@Import(JdbcTemplateV1Config.class)
//@Import(JdbcTemplateV2Config.class)
@Import(JdbcTemplateV3Config.class)
@SpringBootApplication(scanBasePackages = "hello.itemservice.web")
public class ItemServiceApplication {

	public static void main(String[] args) {
		SpringApplication.run(ItemServiceApplication.class, args);
	}

	@Bean
	@Profile("local")
	public TestDataInit testDataInit(ItemRepository itemRepository) {
		return new TestDataInit(itemRepository);
	}

	/* 이 부분 주석 처리 
	@Bean
	@Profile("test")
	public DataSource dataSource() {
		log.info("메모리 데이터베이스 초기화");
		DriverManagerDataSource dataSource = new DriverManagerDataSource();

		dataSource.setDriverClassName("org.h2.Driver");
		dataSource.setUrl("jdbc:h2:mem:db;DB_CLOSE_DELAY=-1");
		dataSource.setUsername("sa");
		dataSource.setPassword("");

		return dataSource;
	}
	 */

}

test - application.properties 에서 주석처리;

spring.profiles.active=test

# 주석처리 --------------------------
#spring.datasource.url=jdbc:h2:tcp://localhost/~/testcase 
#spring.datasource.username=sa
#jdbcTemplate sql log
#---------------------------------

logging.level.org.springframework.jdbc=debug

임베디드 데이터베이스 이름을 스프링 부트가 기본적으로 제공하는 jdbc:h2:mem:testdb 로 고정하고 싶으면 application.properties에 설정 추가하면된다.

spring.datasource.generate-unique-name=false

스프링 부트 3.x 로깅 변경 사항

만약 다음과 같은 트랜잭션 실행, 종료 로그가 보이지 않는다면 application.properties 에 설정을 추가하자.

Began transaction (1) for test context [DefaultTestContext@3f3c966c testClass =
...

Rolled back transaction for test...

org.springframework.test.context.transaction.TransactionContext 에서 남기는 로깅이 INFO
TRACE 로 변경되었다. 참고로 핵심 정보만 출력하려면 DEBUG 를 사용해도 된다.
application.properties

logging.level.org.springframework.test.context.transaction=trace

주의!
- 테스트는 test/resources 폴더에 있는 application.properties 파일을 수정해야 한다.

Navigation Menu

Uh oh!

[스프링 DB 2편] #3. 데이터 접근 기술 - 테스트 #553

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 0 comments

Select a reply

Uh oh!

Uh oh!

[스프링 DB 2편] #3. 데이터 접근 기술 - 테스트 #553

Uh oh!

Uh oh!

YuDeokRin Dec 7, 2024 Maintainer

데이터 접근 기술 - 테스트

1️⃣ 테스트 - 데이터베이스 연동

✅ 환경 설정

✅ 테스트 실행 - 로컬 DB

▶️ 테스트 실행

▶️ 실행 결과

▶️ 실패 원인

2️⃣ 테스트 - 데이터베이스 분리

✅ 데이터 베이스 구분

✅ 테이블 생성하기

✅ 테스트에서 매우 중요한 원칙은 다음과 같다.

3️⃣ 테스트 - 데이터 롤백

✅ 트랜잭션과 롤백 전략

✅ 테스트 실행 하기 전 사전 작업

4️⃣ 테스트 @transactional

✅ 테스트 실행 하기 전 사전 작업

✅ @transactional 원리

✅ @transactional이 적용된 테스트 동작 방식

5️⃣ 테스트 - 임베디드 모드 DB

✅ 임베디드 모드

✅ 임베디드 모드 직접 사용

✅ 스프링 부트 - 기능

6️⃣ 테스트 - 스프링 부트와 임베디드 모드

스프링 부트 3.x 로깅 변경 사항

Replies: 0 comments

YuDeokRin
Dec 7, 2024
Maintainer