테스트 통과하면 천하무적?
213
11 asked
@Test
void calculateTotalPrice() {위에 이미지 처럼 테스트에서 검증 후 ,
아래처럼
public int calculateTotalPrice() {
return beverages.stream().mapToInt(Beverage::getPrice).sum();
}
로 리팩토링 진행하셨는데
테스트코드에서 검증 통과받으면, 프로젝트 코드에서 리팩토링 된 부분은 천하무적이라고 생각하면 되나요 ?
이때 발생하게 되는 변수는 없을련지,,,,
궁금합니다!
Answer 3
1
안녕하세요 정예은 님!
'천하무적'이라고 할 수는 없습니다.
테스트 코드 통과는 소프트웨어의 '완벽함'을 보장하지 않고, 실제 환경에서 예상치 못한 변수로 문제가 발생할 수 있습니다. 하지만 우빈님의 강의를 통해 '좋은 테스트 코드 작성법'을 꾸준히 학습하시다 보면, 리팩터링 시 '더 나은 안정감'을 얻으실 수 있을 것 같아요.
도움이 되셨기를 바랍니다.
감사합니다. 🙂
0
안녕하세요, 정예은 님!
아래 태근님도 잘 답변해 주셨듯이, 아무리 테스트 코드를 잘 작성하더라도 프로덕션 코드를 리팩토링하는 과정에서 생각지 못한 변수가 발생할 수 있습니다.
리팩토링 단계에서 테스트 해야 할 케이스가 추가된다던지, 기존 테스트 코드가 검증하지 못한 케이스가 발견된다던지 하는 일이 있을 수 있어요. (물론 들어주신 예시는 비교적 간단한 예시긴 하지만요.)
테스트 코드는 최소한의 동작을 보장하는, 자동화된 도구라고 이해해주시면 좋을 것 같아요.
도움이 되셨기를 바랍니다.
감사합니다 🙂
0
안녕하세요, 인프런 AI 인턴입니다. 정예은님.
테스트 코드를 활용한 리팩토링 과정에 대해 굉장히 중요한 질문을 주셨네요!
리팩토링과 테스트 통과의 관계
리팩토링 안정성:
- 리팩토링은 코드의 구조 개선을 목적으로 하며, 외부 동작(기능)에는 영향을 주지 않아야 합니다. 테스트가 통과한다는 것은, 코드의 기능적 요구사항이 여전히 충족되고 있다는 것을 의미합니다. 즉, 테스트가 성공하면 리팩토링된 코드가 이전 코드와 동일한 기능을 한다고 믿을 수 있습니다.
- 리팩토링은 코드의 구조 개선을 목적으로 하며, 외부 동작(기능)에는 영향을 주지 않아야 합니다. 테스트가 통과한다는 것은, 코드의 기능적 요구사항이 여전히 충족되고 있다는 것을 의미합니다. 즉, 테스트가 성공하면 리팩토링된 코드가 이전 코드와 동일한 기능을 한다고 믿을 수 있습니다.
테스트 부족 문제:
- 하지만 테스트가 통과한다고 해서 모든 것이 ‘천하무적’이라고 확신할 수는 없습니다. 이는 테스트가 얼마나 철저하느냐에 따라 달라질 수 있습니다. 중요한 포인트는 “테스트 커버리지”입니다. 테스트 커버리지가 충분하지 않으면 개별적이고 예외적인 시나리오가 놓칠 수 있습니다. 이를 통해 기능의 한계나 버그가 숨겨질 수 있습니다.
- 하지만 테스트가 통과한다고 해서 모든 것이 ‘천하무적’이라고 확신할 수는 없습니다. 이는 테스트가 얼마나 철저하느냐에 따라 달라질 수 있습니다. 중요한 포인트는 “테스트 커버리지”입니다. 테스트 커버리지가 충분하지 않으면 개별적이고 예외적인 시나리오가 놓칠 수 있습니다. 이를 통해 기능의 한계나 버그가 숨겨질 수 있습니다.
변수 고려:
- 리팩토링 과정에서 외부 API와의 변화, 시스템 환경의 변화 등이 예상치 못한 문제를 초래할 수 있어, 철저한 테스트 및 코드 검토가 필요합니다.
- 여러 가지 예외 상황과 가장자리를 다루기 위한 추가 테스트 케이스 작성이 필요할 수 있습니다.
- 리팩토링 과정에서 외부 API와의 변화, 시스템 환경의 변화 등이 예상치 못한 문제를 초래할 수 있어, 철저한 테스트 및 코드 검토가 필요합니다.
결론
테스트가 통과함으로써 직접 검증한 기능에 대한 신뢰도는 높지만, 모든 상황을 커버하진 못할 수 있습니다. 따라서 리팩토링 후에도 다양한 시나리오 테스트를 통해 안정성을 더욱 확보할 수 있습니다.
더불어 추가적인 검증을 원하신다면 이 게시물에서 Mock을 이용한 테스트 효과와 관련된 논의가 도움이 될 수 있습니다. 여기서는 테스트가 특히 외부 지향적인 로직에 미치는 영향에 대해 설명합니다. 이를 통해 다양한 테스트 전략을 고려해 보실 수 있습니다.
저는 질문자님의 이해를 돕고자 유사한 문의와 관련된 정보를 제공하였습니다. 궁금한 점이 있으시면 추가적으로 질문해 주세요. 곧 지식공유자께서도 답변을 제공해 주실 것입니다. 🙏
private 상수 테스트 관련 질문
0
82
1
void는 어떻게 테스트하나요..? void로 애초에 코딩하면 안되나요??
0
124
2
커버리지는 어떻게 활용하시는지 궁금합니다.
0
159
2
테스트 문서화 질문입니다
0
104
2
단위테스트 질문이 있습니다
0
94
2
컨트롤러는 모킹을 한 이유가 궁금합니다.
0
100
2
ERD 가장자리에 있는 도메인 테스트 질문
0
86
2
DTO 검증 필드에 대한 테스트 코드 작성은 어디까지?
0
131
2
OrderCreateRequest DTO에 대해서 궁금한점
0
101
2
고전파의 테스트 대역 사용 대상, 공유 의존성
0
154
2
계층 관련 질문이 있습니다.
0
137
3
'코틀린'에서는 빌더를 따로 쓰지 않는데, 이 때는 어떻게 test fixture를 만드시는지 궁금합니다
1
122
2
혹시 update 로직은 어떻게 테스트하나요? (@Setter?)
0
133
2
단위테스트와 통합테스트의 경계가 궁금합니다.
0
226
2
Service+Repository 통합테스트 관련 질문입니다.
0
149
2
OrderControllerDocsTest 작성 해봤는데요. 날짜 형식이 이상하게 나와요
0
183
2
test 용 .yml
0
89
2
throws Exception
0
78
2
카페키오스크 클래스 문의 ,,
0
87
2
Rest docs 문서용 테스트코드를 따로 작성해야 되나요?
0
171
2
테스트 코드에서 필요한 생성자
0
136
1
tearDown 순서
0
114
2
@Builder 생성자 private
0
133
2
@DisplayName gradle / intellJ
0
91
2

