test: TestContainer 적용

[Choi-JJunho]

🔥 연관 이슈

• close TestContainer를 적용한다 #26

🚀 작업 내용

1. testContainer를 적용했습니다.
2. 인수테스트를 위한 설정을 abstract class AcceptanceTest 로 분리했습니다.
   1. 이후 추가로 생성될 인수테스트들은 해당 클래스를 상속받으면 됩니다.
3. DirtiesContext를 사용하던 방식에서 DBInitializer를 사용하는 방식으로 변경했습니다.
   1. 평균 500ms의 테스트 속도를 240ms정도로 줄일 수 있었습니다.
4. application-test.yml 파일을 추가했습니다.
   1. SpringBoot에서는 application-filename 형태로 profile을 정의할 수 있습니다. 예를 들어 applicaiton-dev.yml의 경우 @ActiveProfiles("dev")로 해당 속성을 사용할 수 있습니다.
   2. 참고자료 - Properties with Spring and Spring Boot

💬 리뷰 중점사항

코드레벨에서 큰 변화는 없습니다.
외부 라이브러리를 가져오면서 생소한 내용이 다소 있을 수 있어 최대한 설명을 작성해봤습니다.
관련하여 블로그로도 정리해봤으니 왜 도입하는지, 어떤 방식을 적용했는지 등 자세한 내용은 블로그를 참고해주세요
블로그 - TestContainer 적용하기

[github-actions]

Unit Test Results

4 tests   4 ✔️  3s ⏱️
2 suites  0 💤
2 files    0 ❌

Results for commit 9dfd948.

♻️ This comment has been updated with latest results.

[Invidam]

아직 모르는 부분들, 공부 필요한 부분들이 있는 것 같아 목요일 좀 더 확인해볼게요 !

[Invidam]

Suggested change

	container = new MySQLContainer("mysql:8")
	container = (MySQLContainer) new MySQLContainer("mysql:5.7.34")
	.withDatabaseName("test")
	.withUsername(ROOT)
	.withPassword(ROOT_PASSWORD)
	.withCommand("--character-set-server=utf8mb4", "--collation-server=utf8mb4_unicode_ci")
	;
	container.start();

• Production에서는 5.7.33 버전을 사용중이어서 비슷한 버전으로 다운그레이드 하였구 5.7 버전대는 8.0과 Character Set이 달라, 한글 입력 관련 에러가 터져 수정하는 코드까지 추가해봤습니당
  • (SQLException: Incorrect string value: '\xED\x95\x9C\xEC\x9A\xB0...' for column 'name' at row 1에러가 떴었음.)
• .withCommand() 이용해서 char set 수정했고, 해당 빌더 메서드 이용시 GenericContainer로 반환타입이 변환되어 다시 (MysqlContainer)로 변환했습니다

추가로

• charset 수정을 해당 부분에서 하는 게 맞는지 (schema.sql 에서도 될 것 같고 application.yml에서도 가능할 것 같아요)
• mysql 5.7은 arm(맥기반)이 제공되지 않아 amd 환경의 도커 컨테이너를 이용해야 했는데 괜찮은지 (속도 측면)
• 윈도우는 도커 사용하기 힘든 환경이라고 알고 있는데 사용할 수 있을지 (도커 사용시 메모리 누수가 되었던 경험이 있음)

고민해봐야할 것 같아요 (윈도우인 분들의 테스트가 필요할 것 같네요!!)

[Choi-JJunho]

Production MySQL 버전을 미처 신경쓰지 못했네요!!
좋은 지적 감사합니다 👍

추가로 말씀해주신 내용에 대한 저의 의견을 말씀드려봅니다.

charset 수정을 해당 부분에서 하는 게 맞는지 (schema.sql 에서도 될 것 같고 application.yml에서도 가능할 것 같아요)

해당 MySQL 컨테이너를 띄우는 부분은 오로지 testContainer에서 static하게 단 한번만 사용하므로 전역적으로 yml 파일로 선언하기보다는 작성해주신 대로 해당 코드에서만 사용하는게 어떨까 생각이 듭니다.

별도의 config 파일로 분리할 정도로 중요한 내용이 아니라고 생각되고, 반복되지 않는 작업을 불필요하게 분리하여 관리 요소가 늘어나는 것 같다 라는 의견입니다.

mysql 5.7은 arm(맥기반)이 제공되지 않아 amd 환경의 도커 컨테이너를 이용해야 했는데 괜찮은지 (속도 측면)

속도 측면에서 어떤 부분이 걱정인것인지 정확이 알기 어렵습니다.

5.7을 사용함에 따라 테스트 속도가 느려지는것을 걱정하시는 걸까요? 아니면 컨테이너 로드하는 시간에 대한 걱정일까요?
정확히 얼마나 유의미한 속도차이가 있을지 잘 모르겠네요.

정말 크리티컬하게 속도차이가 나는것이 아니라면 production 환경과 맞춰야하므로 5.7 버전을 사용해야한다 라는 이유가 더 중요하다고 판단되어 트레이드오프 해야하는 부분이라고 생각됩니다.

윈도우는 도커 사용하기 힘든 환경이라고 알고 있는데 사용할 수 있을지 (도커 사용시 메모리 누수가 되었던 경험이 있음)

window docker 환경에서의 메모리 누수에 대한 이슈가 있기도 하군요

• WSL2 + Docker causes severe memory leaks in vmmem process, consuming all my machine's physical memory microsoft/WSL#8725

실제 운영 환경은 Linux 환경이라 해당 부분에 대한 이슈는 없을 것이라고 예상됩니다.

개발자의 로컬 환경에 대한 별도의 처리를 코드레벨에서 고려해야할지는 고민인 부분입니다.
Mac 환경으로 개발하고 있는 상황에서 실제로 경험해보지 못한 부분이기도 하고 정확한 원인을 파악하지 못해 윈도우 사용자의 코멘트가 필요할 것 같네요

해당 의견에 대해서는 직접 사용해본 후 문제가 발생하면 그때 다시 논의해보면 좋을 것 같습니다.
cc. @daheeParkk

[Invidam]

1. charset은 말씀했던대로 TestContainer 레벨에서 처리하는 게 맞을 것 같아요!
   • 실제 프로덕션 환경에 이미 적용이 되어있고, 테스트 환경에서만 적용하면 되기 때문에
2. 5.7에 맞추는 게 더 중요할 것 같고, "칩셋(arm, amd) 차이로 인해 맥 이용시 실행 속도가 느려지거나 동작이 미세하기 다를 수 있다"는 점만 다같이 인지하고 있음 될 것 같아요
3. 테스트 컨테이너가 짧은 시간동안만 실행되고 종료된다는 점을 생각하면 메모리 문제도 그리 심각하지 않을 수 있을 것 같아요!

직접 사용해본 후 문제가 발생하면 그때 다시 논의해보면 좋을 것 같습니다.

👍👍

[Invidam]

https://github.com/ejoongseok/product-order-service/blob/master/src/test/java/com/example/productorderservice/DatabaseCleanup.java
(케이포타운 개발자분의 강의에서 가져온 코드)
비슷하게 DB를 초기화(클린업)하는 코드인데

1. JPA Entity로 사용중인 테이블들만 Truncate
2. 참조 무결성 옵션을 껐다 켜줘서 FK도 제거 가능하도록 설정

의 차이가 있더라구요. (1) 같은 경우는 모든 테이블을 제거하는 것보다 JPA에서 사용한 테이블만 제거하는 것이 성능에 있어 뛰어날 것 같은데 어떻게 생각하세요? (테스트가 필요할까요?)

참고로 강의는 링크

[Choi-JJunho]

좋은 의견이네요!
몇가지 의문점이 있어 코멘트 남겨봅니다.

1. 현재 설계상으로 JPA Entity로 사용중이지 않은 테이블이 있을까요?

사례가 잘 와닿지 않아 해당 방식으로 코드를 구성하는 방향에 대한 의문이 듭니다.

2. 엔티티 이름과 실제 테이블명이 다른 경우

final List<String> entityNames = entities.stream()
        .filter(e -> isEntity(e) && !hasTableAnnotation(e))
        .map(e -> CaseFormat.UPPER_CAMEL.to(CaseFormat.LOWER_UNDERSCORE, e.getName()))
        .toList();

위 코드를 보면 특정 @Entity, @Table 어노테이션이 붙어있는 객체를 가져와 그 객체의 이름을 snake_case로 변환하는 것을 확인 할 수 있습니다.

하지만 해당 방식의 경우 객체 명과 실제 테이블명이 다른 상황에 대한 대처가 어렵다고 생각합니다.

// 예시
@Entity
@Table(name = "students")
public class Student {
// ...
}

3. 성능 개선이 필요할만큼 느린가?

현재 얼마만큼의 속도가 책정되고 저 방식을 적용한다면 얼마만큼의 성능이 개선될지 의문인 상황입니다.

현재로서는 성능 개선이 필요할만큼 속도가 느리다고 생각되지 않는 시점이라 다소 고려를 많이 해보고있다는 부분 양해부탁드립니다. 😅

[Invidam]

1. 지금이나 앞으로나 설계상 JPA Entity로 사용하지 않는 테이블이 떠오르진 않네요
   • 테스트 환경에 대한 이해가 부족해서 실제 서버 환경과 헷갈렸던 것 같아요
   • 따라서 크게 변경할 필요는 없어보이네요!
     • 적용하기 위해선 2번 문제[테이블 명이 다른 경우]도 해결해주어야 하고..
2. 불필요하게 Truncate되었던 테이블의 수만큼 성능이 향상될 것 같은데, 그런 테이블이 없다면 성능 향상은 미미할 것 같네요

[Invidam]

추가로 링크에서 외래키 참조 무결성을 해제했던 쿼리 SET REFERENTIAL_INTEGRITY FALSE은 h2, oracle에서만 가능한 것 같네용..

참고 링크

[Invidam]

Suggested change

	RestAssured.port = port;
	if (RestAssured.port == RestAssured.UNDEFINED_PORT) {
	RestAssured.port = port;
	}

로 UNDEFINED인 경우에만 넣어주는 건 어떨까요?

[Choi-JJunho]

오! 좋습니다~!

[Invidam]

https://tecoble.techcourse.co.kr/post/2020-09-15-test-isolation/ 의 댓글이나
https://yeon-kr.tistory.com/212 글을 봤는데,

병렬 테스팅하여 멀티쓰레드로 테스트를 실행해보는 건 어떨까요?

[Choi-JJunho]

https://tecoble.techcourse.co.kr/post/2020-09-15-test-isolation/ 의 댓글이나 https://yeon-kr.tistory.com/212 글을 봤는데,

병렬 테스팅하여 멀티쓰레드로 테스트를 실행해보는 건 어떨까요?

Junit5에 병렬테스팅 기능이 있군요!
해당 기능에 대한 추가학습을 진행한 뒤 적용해보겠습니다~! (화요일까지 적용해보겠습니다)

[songsunkook]

블로그 잘 읽었습니다.

TestContainer를 도입하는 과정에서 컨테이너 생성을 직접 제어하니 실행 속도가 훨씬 빨라지는 점이 인상깊습니다. TestContainer를 도입할 때는 해당 과정이 거의 필수로 보이네요..!

새로운 기술 스택 도입인 만큼 낯설었을 텐데 고생하셨습니다! 👍

[songsunkook]

이 부분은 application-test.yml과 같은 설정 파일에 분리할 수 있을 것 같은데, 따로 분리하지 않은 이유가 있을까요??

[Choi-JJunho]

위에서 한수에게 답변한 내용과 동일합니다~

• test: TestContainer 적용 #27 (comment)

charset 수정을 해당 부분에서 하는 게 맞는지 (schema.sql 에서도 될 것 같고 application.yml에서도 가능할 것 같아요)

해당 MySQL 컨테이너를 띄우는 부분은 오로지 testContainer에서 static하게 단 한번만 사용하므로 전역적으로 yml 파일로 선언하기보다는 작성해주신 대로 해당 코드에서만 사용하는게 어떨까 생각이 듭니다.

별도의 config 파일로 분리할 정도로 중요한 내용이 아니라고 생각되고, 반복되지 않는 작업을 불필요하게 분리하여 관리 요소가 늘어나는 것 같다 라는 의견입니다.

[Choi-JJunho]

@Invidam

https://tecoble.techcourse.co.kr/post/2020-09-15-test-isolation/ 의 댓글이나 https://yeon-kr.tistory.com/212 글을 봤는데,

병렬 테스팅하여 멀티쓰레드로 테스트를 실행해보는 건 어떨까요?

공유해주신 https://yeon-kr.tistory.com/212 글을 적용해봤습니다.
properties 파일을 이용한 설정으로 아주 간단한 설정이였으나 현재 테스트 개수가 너무 적어 유의미한 결과가 나오질 않습니다.
제 로컬 기준 빌드 타임이 24s에서 23s로 개선되는 아주 미비한 효과를 보이네요..

테스트 병렬처리는 테스트가 조금 더 쌓이고 추후에 도입해보는건 어떨까요? 지금으로서 적용해도 좋은 방법인지는 의문이 듭니다.

[Invidam]

동의합니다~ 여러 테스트로 인해 시간소요가 많아질 때 고민하는 게 효과적일 것 같네요

[daheeParkk]

TestContainer에 대해 새롭게 알게되었습니다!
작성해주신 블로그를 보면서 코드를 봐서 이해하기 편했습니다. (동작 원리에 대해서는 좀 더 공부해봐야 할 것 같습니다..!)

[daheeParkk]

설정을 클래스로 따로 분리해서, 인수 테스트를 생성할 때는 해당 클래스를 상속만 받으면 되니까 편리하고 보기 좋은 것 같습니다!

이름은 왜 Acceptance인가요?

[Choi-JJunho]

인수테스트에 해당 클래스를 상속받게 만들고자했습니다~!
용어는 인수 검사(acceptance testing)에서 따왔습니다

참고: https://ko.wikipedia.org/wiki/%EC%9D%B8%EC%88%98_%EA%B2%80%EC%82%AC

[daheeParkk]

설정이 test, 1234로 되어 있는데 아무거나 넣어도 되는 건가요?

[Choi-JJunho]

넹 아무거나 넣어도 됩니다~!
테스트용이라 아무거나 넣었어요