[Suggest] Test & Build 에 관한 고민

[pbg0205]

🙋🏻‍♂️ 제안 사항

현재 빌드시 테스트 구조의 개선이 필요해 보입니다

1. 통합 테스트 또는 DB 슬라이싱 테스트의 경우, 운영 DB 를 의존하여 테스트를 동작하고 있습니다. 운영 DB 에 의존하고 있는 테스트 코드는 변경이 어려울 뿐만 아니라 비용적인 측면에서도 단점이 있습니다.
2. 매번 테스트 코드를 동작시킬 때마다 테이블 생성, 삭제에 관한 I/O 가 증가함에 따라 그만큼 서버 리소스를 많이 소비합니다. 현재 AWS 를 사용하고 있는 상황에서 리소스 사용은 곧 비용적인 측면에서도 고려해야할 사항입니다.
3. 빌드 서버에서 운영 DB 를 접근하는 방법은 상당히 위험합니다. 일반적으로 운영 DB 의 경우 private-subnet 을 구성하여 외부의 접근을 최소화 하는 형태의 서버 구조를 가지지만 빌드 서버에서 운영 서버에 관한 접근할 경우 테스트 과정에서 실제 사용자의 데이터가 유실될 수 있는 위험성이 있습니다. 이를 개선하는 용도로 별도의 빌드 DB 서버를 구성하거나 TestContainer 를 효율적으로 사용하는 방법에 관한 고민이 필요해 보입니다.
4. 현재 서비스를 운영하고 있는 상황은 아니지만 프로젝트의 유지보수와 서버 운영 관점에서 필요할 것 같습니다. 현재의 기술 부채로 인해 당장 적용할 수 없을지라도 추가적인 학습을 통해 개선이 필요해 보입니다.
5. 결론 : 테스트 격리 환경에 대해 고민해보자.

운영 환경에 관한 설정 변경가 필요합니다

• 일반적으로 운영환경의 경우에는 ddl-auto option 이 update 또는 none 을 사용
• 각 운영 환경에 따른 property 구분하는 방법이 필요.

[zbqmgldjfh]

음 하나 궁금한점이 있습니다??
저희의 애플리케이션은 현재 테스트 실행시 전부 TestContainer로 수행중입니다, URL부터 test용 url이죠!

jdbc:tc:mysql:8

즉, 현 테스트 구조는 운영 DB와 완전히 분리된 구조 아닌가요??

[pbg0205]

아 DB 환경은 프로퍼티를 통해서 분리되어 있었네요~ 그러면 테스트 동작 시간을 고민해봐야겠네요. 테스트 시간이 20분 넘게 걸리고 있어서 이를 개선할 요소가 필요해 보입니다

[zbqmgldjfh]

테스트 수행시간을 빠르게 하는 방법으로 멀티스레드를 활용한 테스트 수행을 하는 방법이 있는것으로 알고 있습니다!!

20분은 좀 심하긴 한데... 이게 테스트 자체가 오래 걸리기 보다는, 테스트 수행을 위한 Docker자체를 띄우고 실행하는데 시간이 너무 오래걸리는 것 같습니다. 그전까지만 해도 TestContainer를 사용하지 않았다면 3분 미만 이였으니까요!!

사실 가장 간단한건 TestContainer를 안쓰고 CI용 DB를 하나 만들어주면 금방 해결될것 같다 생각됩니다 ㅎㅎ

[pbg0205]

이 부분도 고민을 좀 해봐야겠네요.. DB에 관한 의존성을 줄이는 목적으로 TestContainer 를 사용한 이유가 분명하고 테스트 고립성에서도 장점이 있어서 어떻게 개선할지 한번 고민해봐도 좋을 것 같아요 😃

[zbqmgldjfh]

일단 병목 지점인 Container방식의 Test가 느린 이유부터 좀 찾아보겠습니다 ㅎㅎ
T3.mideum을 쓰고 있는 상황에서 단순 성능 문제만은 아닐수도 있단 생각도 드네요 ㅎㅎ