test: DataSource 학습 테스트에서 설정 하드코딩 제거 및 properties 로드 적용 #961
Conversation
Walkthrough테스트 코드에서 하드코딩된 H2 접속 상수를 제거하고 클래스패스의 Pre-merge checks❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🧪 Early access (Sonnet 4.5): enabledWe are currently testing the Sonnet 4.5 model, which is expected to improve code review quality. However, this model may lead to increased noise levels in the review comments. Please disable the early access features if the noise level causes any inconvenience. Note:
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
study/src/test/java/connectionpool/stage0/Stage0Test.java (1)
55-58: 리소스 누락 시 명확한 에러 처리 추가 제안
ClassLoader.getResourceAsStream("db.properties")가 리소스를 찾지 못하면null을 반환해 이후props.load(input)에서 NPE가 발생할 수 있습니다.
리소스 로딩 직후에Objects.requireNonNull(input, "db.properties 파일을 찾을 수 없습니다")또는 명시적 null 검사 후IllegalStateException등을 던져 명확한 예외 메시지를 제공하도록 수정해주세요.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
study/src/test/java/connectionpool/stage0/Stage0Test.java(2 hunks)study/src/test/resources/db.properties(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.java
⚙️ CodeRabbit configuration file
**/*.java: ## 🎯 코드 품질 중심 리뷰 가이드라인이 리뷰는 코드 품질과 객체지향 원칙에 집중합니다.
미션 달성 여부가 아닌, 코드 설계와 품질 개선에 대한 피드백을 한글로 제공해주세요.📚 학습 원칙
- 직접 코드를 제공하지 마세요 (학습자가 명시적으로 요청하는 경우 제외)
- 문제 해결 과정을 안내하되, 정답을 바로 알려주지 마세요
- 작은 단계로 문제를 분해하여 접근하도록 도와주세요
💡 피드백 방법
- 유도 질문 활용: "만약 ~라면 어떻게 될까요?", "~를 고려해보셨나요?"
- 힌트 제공: 방향은 제시하되, 구체적인 구현은 학습자가 하도록
- 다양한 접근법 제시: 한 가지 해결책이 아닌 여러 가능성을 제안
- 왜?에 집중: 단순히 무엇이 잘못되었는지보다 왜 그런지 이해하도록
⚡ 객체지향 생활 체조 원칙 검토
다음은 객체지향 생활 체조(Object Calisthenics) 9가지 원칙입니다.
위반 시 학습 효과를 위해 반드시 피드백을 제공하되, 왜 이 원칙이 중요한지 설명해주세요:규칙 1: 한 메서드에 오직 한 단계의 들여쓰기만
- 들여쓰기 depth 최대 1 (중첩 제어구조 금지)
- 📖 이유: 메서드 복잡도 감소, 단일 책임 원칙 강화
- 💡 힌트: "이 부분을 별도 메서드로 추출하면 어떨까요?"
규칙 2: else 예약어 금지
- else, switch/case 사용 금지
- 📖 이유: 복잡한 분기 제거, 명확한 코드 흐름
- 💡 힌트: "early return이나 가드 클로즈 패턴을 고려해보세요"
규칙 3: 모든 원시값과 문자열 포장
- 원시 타입과 String을 객체로 포장
- 📖 이유: 도메인 개념 명확화, 비즈니스 로직 응집
- 💡 예시:
int port→Port port,String name→Name name규칙 4: 한 줄에 점 하나만 (디미터 법칙)
- 메서드 체이닝 제한
- 📖 이유: 결합도 감소, 캡슐화 향상
- 💡 나쁜 예:
request.getUri().getPath().substring()- 💡 좋은 예:
request.extractPath()규칙 5: 축약 금지
- 명확한 이름 사용 (축약어 금지)
- 📖 이유: 코드 가독성, 의도 명확화
- 💡 예시:
req→request,calcAmt→calculateAmount규칙 6: 모든 엔티티를 작게 유지
- 클래스 50줄, 메서드 10줄 이하
- 📖 이유: 단일 책임, 이해와 테스트 용이성
- 💡 힌트: "이 클래스가 너무 많은 일을 하고 있지 않나요?"
규칙 7: 인스턴스 변수 3개 이하
- 클래스당 최대 3개의 인스턴스 변수
- 📖 이유: 높은 응집도, 단일 책임 유지
- 💡 힌트: "관련 필드들을 별도 객체로 묶을 수 있을까요?"
규칙 8: 일급 컬렉션 사용
- 컬렉션을 감싸는 클래스 사용
- 📖 이유: 컬렉션 로직 캡슐화, 불변성 보장
- 💡 예시:
List<HttpHeader>→HttpHeaders클래스규칙 9: 게터/세터/프로퍼티 금지
- Tell, Don't Ask 원칙 준수
- 📖 이유: 진정한 캡슐화, 객체 자율성
- 💡 나쁜 예:
if (user.getPassword().equals(input))- 💡 좋은 예:
if (user.authenticate(input))🎯 추가 프로그래밍 요구사항
코드 스타일
- Java Style Guide 준수
- 3항 연산자 사용 금지
테스트 및 구조
- **모든 기능 T...
Files:
study/src/test/java/connectionpool/stage0/Stage0Test.java
🔇 Additional comments (2)
study/src/test/resources/db.properties (1)
1-3: 학습 테스트용 설정으로 적절합니다.H2 인메모리 데이터베이스 설정이 테스트 목적에 맞게 잘 구성되어 있습니다. 이 변경으로 코드에서 하드코딩된 설정을 제거하고 외부 설정 파일로 관리할 수 있게 되었네요. DataSource의 장점인 "외부 설정을 통한 유연한 구성"을 잘 보여주는 예시입니다.
study/src/test/java/connectionpool/stage0/Stage0Test.java (1)
60-63: 외부 설정 파일 활용이 잘 적용되었습니다.하드코딩된 DB 연결 정보를
properties파일에서 읽어오도록 변경하여, PR의 목적인 "DataSource의 외부 설정을 통한 유연한 구성"을 명확하게 보여주고 있습니다.이 변경으로 학습자는
DriverManager(하드코딩 필요)와DataSource(외부 설정 가능)의 차이를 직접 경험할 수 있게 되었네요.추가로 고민해볼 점:
- 만약
db.properties에db.url키가 없다면 어떻게 될까요?getProperty()가null을 반환할 때의 동작을 테스트해보면 어떨까요?더 견고한 구현을 원한다면 속성 값의 존재 여부를 검증하는 것도 고려해볼 수 있지만, 학습 테스트의 목적에서는 현재 구현으로도 충분합니다.
Starlight258
force-pushed
the
test/jdbc
branch
from
4acc5b1 to
1c24383
Compare
Starlight258
force-pushed
the
test/jdbc
branch
from
1c24383 to
54137b3
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
study/src/test/java/connectionpool/stage0/Stage0Test.java (1)
3-87: 전체적으로 학습 목표를 잘 달성한 리팩토링입니다! 🎯하드코딩된 DB 설정을 외부 프로퍼티 파일로 분리하여,
DataSource의 핵심 장점인 "설정 변경 시 코드 수정 불필요"를 명확히 보여줍니다.✅ 잘된 점:
- DriverManager vs DataSource 비교 구조가 명확함
- 리소스 관리(try-with-resources) 적절히 사용
- 주석으로 학습 포인트를 효과적으로 전달
⚠️ 수정 필요:
loadProps()의 null 체크 누락 (위 코멘트 참고)🤔 추가 학습 고민:
- 프로퍼티 값이 누락되었을 때는 어떻게 처리하면 좋을까요? (예:
db.url키가 없는 경우)- 테스트 격리를 위해 각 테스트마다 독립적인 DB 인스턴스를 사용하는 것이 좋을까요?
PR의 draft 상태 언급을 보았는데, 수정 후 다시 리뷰 요청 주시면 확인하겠습니다! 💪
🧹 Nitpick comments (2)
study/src/test/java/connectionpool/stage0/Stage0Test.java (2)
32-44: DriverManager 테스트가 학습 목표를 잘 보여줍니다.하드코딩된 DB 정보를 프로퍼티 파일에서 읽어오도록 변경하여, 설정 외부화의 장점을 명확히 드러냅니다.
🤔 개선 고민: 37-39번 라인의 변수 선언이 꼭 필요할까요?
try (final Connection conn = DriverManager.getConnection( props.getProperty(PROPERTY_DB_URL), props.getProperty(PROPERTY_DB_USER), props.getProperty(PROPERTY_DB_PASSWORD))) {이렇게 인라인으로 작성하면 어떤 장단점이 있을지 생각해보세요. (가독성 vs 간결성)
61-79: DataSource의 장점을 효과적으로 보여주는 테스트입니다.74번 라인의 "사용부는 인터페이스만 의존" 주석이 핵심 학습 포인트를 잘 강조합니다. 구현체(
JdbcDataSource)를 설정하고, 인터페이스(DataSource)로 사용하는 패턴이 명확합니다.💭 생각해볼 점: 64-71번 라인에서 프로퍼티를 읽고 설정하는 패턴이 반복됩니다.
final String url = props.getProperty(PROPERTY_DB_URL); jdbcDataSource.setURL(url); final String user = props.getProperty(PROPERTY_DB_USER); jdbcDataSource.setUser(user);학습 테스트에서는 명시적인 것이 좋지만, 실제 프로덕션 코드라면 이런 반복을 어떻게 줄일 수 있을까요?
- 빌더 패턴을 사용한다면?
- 설정 전용 메서드를 추출한다면?
현재 코드는 학습 목적상 각 단계를 명확히 보여주므로 적절하지만, DRY 원칙 관점에서 한번 고민해보시면 좋겠습니다.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
study/src/test/java/connectionpool/stage0/Stage0Test.java(3 hunks)study/src/test/resources/db.properties(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- study/src/test/resources/db.properties
🧰 Additional context used
📓 Path-based instructions (1)
**/*.java
⚙️ CodeRabbit configuration file
**/*.java: ## 🎯 코드 품질 중심 리뷰 가이드라인이 리뷰는 코드 품질과 객체지향 원칙에 집중합니다.
미션 달성 여부가 아닌, 코드 설계와 품질 개선에 대한 피드백을 한글로 제공해주세요.📚 학습 원칙
- 직접 코드를 제공하지 마세요 (학습자가 명시적으로 요청하는 경우 제외)
- 문제 해결 과정을 안내하되, 정답을 바로 알려주지 마세요
- 작은 단계로 문제를 분해하여 접근하도록 도와주세요
💡 피드백 방법
- 유도 질문 활용: "만약 ~라면 어떻게 될까요?", "~를 고려해보셨나요?"
- 힌트 제공: 방향은 제시하되, 구체적인 구현은 학습자가 하도록
- 다양한 접근법 제시: 한 가지 해결책이 아닌 여러 가능성을 제안
- 왜?에 집중: 단순히 무엇이 잘못되었는지보다 왜 그런지 이해하도록
⚡ 객체지향 생활 체조 원칙 검토
다음은 객체지향 생활 체조(Object Calisthenics) 9가지 원칙입니다.
위반 시 학습 효과를 위해 반드시 피드백을 제공하되, 왜 이 원칙이 중요한지 설명해주세요:규칙 1: 한 메서드에 오직 한 단계의 들여쓰기만
- 들여쓰기 depth 최대 1 (중첩 제어구조 금지)
- 📖 이유: 메서드 복잡도 감소, 단일 책임 원칙 강화
- 💡 힌트: "이 부분을 별도 메서드로 추출하면 어떨까요?"
규칙 2: else 예약어 금지
- else, switch/case 사용 금지
- 📖 이유: 복잡한 분기 제거, 명확한 코드 흐름
- 💡 힌트: "early return이나 가드 클로즈 패턴을 고려해보세요"
규칙 3: 모든 원시값과 문자열 포장
- 원시 타입과 String을 객체로 포장
- 📖 이유: 도메인 개념 명확화, 비즈니스 로직 응집
- 💡 예시:
int port→Port port,String name→Name name규칙 4: 한 줄에 점 하나만 (디미터 법칙)
- 메서드 체이닝 제한
- 📖 이유: 결합도 감소, 캡슐화 향상
- 💡 나쁜 예:
request.getUri().getPath().substring()- 💡 좋은 예:
request.extractPath()규칙 5: 축약 금지
- 명확한 이름 사용 (축약어 금지)
- 📖 이유: 코드 가독성, 의도 명확화
- 💡 예시:
req→request,calcAmt→calculateAmount규칙 6: 모든 엔티티를 작게 유지
- 클래스 50줄, 메서드 10줄 이하
- 📖 이유: 단일 책임, 이해와 테스트 용이성
- 💡 힌트: "이 클래스가 너무 많은 일을 하고 있지 않나요?"
규칙 7: 인스턴스 변수 3개 이하
- 클래스당 최대 3개의 인스턴스 변수
- 📖 이유: 높은 응집도, 단일 책임 유지
- 💡 힌트: "관련 필드들을 별도 객체로 묶을 수 있을까요?"
규칙 8: 일급 컬렉션 사용
- 컬렉션을 감싸는 클래스 사용
- 📖 이유: 컬렉션 로직 캡슐화, 불변성 보장
- 💡 예시:
List<HttpHeader>→HttpHeaders클래스규칙 9: 게터/세터/프로퍼티 금지
- Tell, Don't Ask 원칙 준수
- 📖 이유: 진정한 캡슐화, 객체 자율성
- 💡 나쁜 예:
if (user.getPassword().equals(input))- 💡 좋은 예:
if (user.authenticate(input))🎯 추가 프로그래밍 요구사항
코드 스타일
- Java Style Guide 준수
- 3항 연산자 사용 금지
테스트 및 구조
- **모든 기능 T...
Files:
study/src/test/java/connectionpool/stage0/Stage0Test.java
🔇 Additional comments (1)
study/src/test/java/connectionpool/stage0/Stage0Test.java (1)
15-18: 학습 테스트로서 적절한 상수 정의입니다.프로퍼티 파일명과 키를 상수로 분리하여 중복을 제거하고 유지보수성을 높였습니다.
💡 학습 포인트: 객체지향 생활 체조 원칙 3(모든 원시값과 문자열 포장)에 따르면 이런 문자열들도
DatabasePropertyKey같은 객체로 감쌀 수 있지만, 학습 테스트의 단순성을 고려하면 현재 방식도 충분히 합리적입니다.
| private Properties loadProps() throws Exception { | ||
| Properties props = new Properties(); | ||
| try (InputStream in = getClass().getClassLoader().getResourceAsStream(DB_PROPERTIES)) { | ||
| props.load(in); | ||
| } | ||
| return props; | ||
| } |
There was a problem hiding this comment.
리소스 로딩 시 null 체크가 누락되었습니다.
getResourceAsStream()은 리소스를 찾지 못하면 null을 반환합니다. 83번 라인에서 null 체크 없이 84번 라인에서 props.load(in)을 호출하면 NullPointerException이 발생합니다.
🚨 문제 상황:
db.properties파일이 없거나 경로가 잘못된 경우- NPE가 발생하여 실제 원인(파일 없음)을 파악하기 어려움
💡 개선 방향:
만약 in이 null이라면 어떻게 처리하는 것이 좋을까요?
- 명확한 예외 메시지를 던지는 방법
- 파일 존재 여부를 먼저 검증하는 방법
학습 테스트에서 의미 있는 실패 메시지를 제공하는 것도 중요한 부분입니다. 어떤 방식으로 개선할 수 있을지 고민해보세요.
🤖 Prompt for AI Agents
In study/src/test/java/connectionpool/stage0/Stage0Test.java around lines 81 to
87, the InputStream returned by getResourceAsStream(DB_PROPERTIES) is not
null-checked before calling props.load(in), which will throw a
NullPointerException if the resource is missing; update the method to check if
in is null and, when it is, throw a clear Exception (or AssertionError) with a
descriptive message like "db.properties not found on classpath: <DB_PROPERTIES>"
(or fail the test) so failures indicate missing file rather than NPE, and keep
the try-with-resources for non-null streams.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
study/src/test/java/connectionpool/stage0/Stage0Test.java (1)
81-87: 이전 리뷰의 null 체크 이슈가 여전히 해결되지 않았습니다.
getResourceAsStream()은 리소스를 찾지 못할 경우null을 반환합니다. 84번 라인에서 null 체크 없이props.load(in)을 호출하면NullPointerException이 발생합니다.🚨 문제 상황:
db.properties파일이 클래스패스에 없거나 경로가 잘못된 경우- NPE 발생으로 실제 원인(파일 부재)을 파악하기 어려움
💡 개선 방향:
학습 테스트에서 의미 있는 실패 메시지를 제공하는 것이 중요합니다. 다음을 고려해보세요:
in이null인 경우를 먼저 확인null일 때 명확한 메시지와 함께 예외를 던지기- 예:
"db.properties 파일을 클래스패스에서 찾을 수 없습니다: " + DB_PROPERTIES이렇게 하면 테스트 실패 시 원인을 즉시 파악할 수 있습니다.
🤖 Prompt for AI Agents
In study/src/test/java/connectionpool/stage0/Stage0Test.java around lines 81 to 87, the InputStream returned by getResourceAsStream(DB_PROPERTIES) is not null-checked before calling props.load(in), which will throw a NullPointerException if the resource is missing; update the method to check if in is null and, when it is, throw a clear Exception (or AssertionError) with a descriptive message like "db.properties not found on classpath: <DB_PROPERTIES>" (or fail the test) so failures indicate missing file rather than NPE, and keep the try-with-resources for non-null streams.
🧹 Nitpick comments (2)
study/src/test/java/connectionpool/stage0/Stage0Test.java (2)
35-39: 프로퍼티 추출 로직의 중복을 고려해보세요.
loadProps()를 호출한 후 세 가지 프로퍼티(db.url,db.user,db.password)를 추출하는 패턴이dataSource()테스트와 동일하게 반복됩니다.💡 개선 방향 힌트:
- 이 세 가지 프로퍼티를 하나의 객체로 묶어 반환하는 방법은 어떨까요?
- 예:
DatabaseConfig같은 객체를 만들어 관련된 설정값들을 응집시킬 수 있습니다.다만 학습 테스트의 목적이 명확성에 있다면 현재 방식도 충분히 이해하기 쉽습니다. 중복 제거와 명확성 사이에서 어떤 것이 더 중요한지 고민해보세요.
64-74: DataSource 인터페이스 분리가 학습 목적을 잘 드러냅니다.구현체(
JdbcDataSource) 설정과 인터페이스(DataSource) 사용을 명확히 분리하여 의존성 역전을 보여주는 좋은 예시입니다.다만 프로퍼티 추출 부분(66, 68, 70번 라인)에서 변수 선언과 사용이 분리되어 있어 약간의 개선 여지가 있습니다.
💡 가독성 개선 제안:
jdbcDataSource.setURL(props.getProperty(PROPERTY_DB_URL)); jdbcDataSource.setUser(props.getProperty(PROPERTY_DB_USER)); jdbcDataSource.setPassword(props.getProperty(PROPERTY_DB_PASSWORD));위처럼 중간 변수 없이 직접 전달하면 더 간결할 수 있습니다. 하지만 현재 방식도 각 값을 명확히 보여주므로 학습 목적에는 적합합니다.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
study/src/test/java/connectionpool/stage0/Stage0Test.java(3 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.java
⚙️ CodeRabbit configuration file
**/*.java: ## 🎯 코드 품질 중심 리뷰 가이드라인이 리뷰는 코드 품질과 객체지향 원칙에 집중합니다.
미션 달성 여부가 아닌, 코드 설계와 품질 개선에 대한 피드백을 한글로 제공해주세요.📚 학습 원칙
- 직접 코드를 제공하지 마세요 (학습자가 명시적으로 요청하는 경우 제외)
- 문제 해결 과정을 안내하되, 정답을 바로 알려주지 마세요
- 작은 단계로 문제를 분해하여 접근하도록 도와주세요
💡 피드백 방법
- 유도 질문 활용: "만약 ~라면 어떻게 될까요?", "~를 고려해보셨나요?"
- 힌트 제공: 방향은 제시하되, 구체적인 구현은 학습자가 하도록
- 다양한 접근법 제시: 한 가지 해결책이 아닌 여러 가능성을 제안
- 왜?에 집중: 단순히 무엇이 잘못되었는지보다 왜 그런지 이해하도록
⚡ 객체지향 생활 체조 원칙 검토
다음은 객체지향 생활 체조(Object Calisthenics) 9가지 원칙입니다.
위반 시 학습 효과를 위해 반드시 피드백을 제공하되, 왜 이 원칙이 중요한지 설명해주세요:규칙 1: 한 메서드에 오직 한 단계의 들여쓰기만
- 들여쓰기 depth 최대 1 (중첩 제어구조 금지)
- 📖 이유: 메서드 복잡도 감소, 단일 책임 원칙 강화
- 💡 힌트: "이 부분을 별도 메서드로 추출하면 어떨까요?"
규칙 2: else 예약어 금지
- else, switch/case 사용 금지
- 📖 이유: 복잡한 분기 제거, 명확한 코드 흐름
- 💡 힌트: "early return이나 가드 클로즈 패턴을 고려해보세요"
규칙 3: 모든 원시값과 문자열 포장
- 원시 타입과 String을 객체로 포장
- 📖 이유: 도메인 개념 명확화, 비즈니스 로직 응집
- 💡 예시:
int port→Port port,String name→Name name규칙 4: 한 줄에 점 하나만 (디미터 법칙)
- 메서드 체이닝 제한
- 📖 이유: 결합도 감소, 캡슐화 향상
- 💡 나쁜 예:
request.getUri().getPath().substring()- 💡 좋은 예:
request.extractPath()규칙 5: 축약 금지
- 명확한 이름 사용 (축약어 금지)
- 📖 이유: 코드 가독성, 의도 명확화
- 💡 예시:
req→request,calcAmt→calculateAmount규칙 6: 모든 엔티티를 작게 유지
- 클래스 50줄, 메서드 10줄 이하
- 📖 이유: 단일 책임, 이해와 테스트 용이성
- 💡 힌트: "이 클래스가 너무 많은 일을 하고 있지 않나요?"
규칙 7: 인스턴스 변수 3개 이하
- 클래스당 최대 3개의 인스턴스 변수
- 📖 이유: 높은 응집도, 단일 책임 유지
- 💡 힌트: "관련 필드들을 별도 객체로 묶을 수 있을까요?"
규칙 8: 일급 컬렉션 사용
- 컬렉션을 감싸는 클래스 사용
- 📖 이유: 컬렉션 로직 캡슐화, 불변성 보장
- 💡 예시:
List<HttpHeader>→HttpHeaders클래스규칙 9: 게터/세터/프로퍼티 금지
- Tell, Don't Ask 원칙 준수
- 📖 이유: 진정한 캡슐화, 객체 자율성
- 💡 나쁜 예:
if (user.getPassword().equals(input))- 💡 좋은 예:
if (user.authenticate(input))🎯 추가 프로그래밍 요구사항
코드 스타일
- Java Style Guide 준수
- 3항 연산자 사용 금지
테스트 및 구조
- **모든 기능 T...
Files:
study/src/test/java/connectionpool/stage0/Stage0Test.java
🔇 Additional comments (1)
study/src/test/java/connectionpool/stage0/Stage0Test.java (1)
15-18: 상수 선언이 적절합니다.프로퍼티 파일명과 키 값들을 상수로 분리하여 하드코딩을 제거한 점이 좋습니다. 상수 네이밍도 Java 관례를 잘 따르고 있습니다.
1 participant
학습 테스트에서 보듯이
DriverManager와 달리DataSource는 인터페이스이므로, 외부 설정을 기반으로 쉽게 교체 가능하다는 점이 큰 장점입니다.기존 테스트는 단순히 연결 여부만 확인하기 때문에,
이번 수정에서는 "애플리케이션 코드를 직접 수정하지 않고 DB 연결을 변경할 수 있다" 는
DataSource의 장점을 드러내도록 개선했습니다 🙇♀️