[OpenSource] WET vs DRY(feat 오픈소스기여)

오픈소스 기여를 통해 배운 유닛 테스트: WET vs DRY

최근 Apache 오픈소스 프로젝트에 기여하면서 유닛 테스트 작성에 대한 흥미로운 고민에 빠졌습니다. PR(Pull Request)을 보내는 과정에서 기존 테스트 코드와의 중복 문제에 부딪혔고, 이 과정에서 WET(Write Everything Twice)과 DRY(Don't Repeat Yourself) 원칙에 대한 인사이트를 경험했습니다.

---

시작은 코드 중복에 대한 고민

제가 맡았던 이슈에 대한 유닛 테스트를 작성하던 중, 기존의 update model 테스트들과 상당한 코드 중복이 발생한다는 것을 발견했습니다. 처음에는 테스트 문자열을 바꾸는 임시방편으로 문제를 해결했지만, '과연 이것이 이 코드베이스에서 더 나은, 관용적인 방법일까?'라는 의문이 들었습니다.

이러한 고민을 안고 PR을 보냈을 때, 멘토이신 @jerryshao님께 질문을 드렸습니다.

"May I ask a question?, I've got unit tests written for the current issue, but I hit some significant code duplication with the existing update model tests. I've worked around it for now by changing the target string used in the test, but I'm wondering if there's a better, more idiomatic way to handle this in our codebase. Any thoughts on that?"

추가적으로, #RESTUtils.encodeString()을 사용하는 여러 메서드에 인코딩 테스트가 부족하다는 점도 발견하여 이에 대한 처리 방향도 함께 문의했습니다.

---

멘토의 답변: "WET vs DRY" 그리고 테스트 코드의 특성

질문에 대한 답변은 저에게 큰 깨달음을 주었습니다. Apache 프로젝트의 멤버이신 @justinmclean님께서 다음과 같이 코멘트해 주셨습니다.

"Duplicate code in unit tests is usually is not a big issue - see WET vs DRY."

이 답변은 "유닛 테스트에서의 코드 중복은 보통 큰 문제가 아니다"라는 핵심적인 메시지와 함께 WET(Write Everything Twice)과 DRY(Don't Repeat Yourself) 원칙을 언급했습니다.

DRY(Don't Repeat Yourself)

소프트웨어 개발에서 DRY 원칙은 "모든 지식 조각은 시스템 내에서 단일하고, 권위 있고, 모호하지 않게 표현되어야 한다"는 개념입니다. 즉, 동일한 로직이나 데이터는 여러 번 반복해서 작성하지 말고, 한 곳에 모아 재사용성을 높여야 한다는 것입니다. 이는 코드의 유지보수성을 높이고 버그 발생 가능성을 줄이는 데 기여합니다.

WET(Write Everything Twice)

반면, WET은 DRY의 반대 개념처럼 보이지만, 특정 상황, 특히 테스트 코드에서는 오히려 유용할 수 있는 접근 방식입니다. WET은 코드 중복을 일부러 허용하는 전략으로, 각각의 테스트 케이스가 독립적이고 이해하기 쉽게 작성되는 데 중점을 둡니다.

---

왜 유닛 테스트에서는 WET이 어느정도 용인될까?

유닛 테스트에서 코드 중복이 '큰 문제'가 아닌 이유는 다음과 같습니다.

• 독립성과 가독성: 각 유닛 테스트는 독립적으로 실행되어야 하며, 특정 기능을 명확하게 테스트해야 합니다. 만약 테스트 코드를 지나치게 추상화하여 DRY 원칙을 엄격하게 적용하면, 테스트 코드가 복잡해지고 특정 테스트 케이스가 어떤 시나리오를 검증하는지 파악하기 어려워질 수 있습니다. WET은 각 테스트가 자체적으로 완전하고 이해하기 쉽게 만듭니다.
• 쉬운 디버깅: 테스트가 실패했을 때, 중복된 코드로 인해 여러 테스트가 동시에 실패하는 것보다, 각 테스트가 독립적이라면 문제의 원인을 더 빠르고 정확하게 파악할 수 있습니다.
• 유연성: 특정 테스트 케이스의 요구사항이 변경되더라도, 다른 테스트에 미치는 영향을 최소화하면서 해당 테스트만 수정할 수 있습니다. DRY를 과도하게 적용하면 하나의 변경이 여러 테스트에 파급되어 예상치 못한 버그를 유발할 수 있습니다.

물론, 테스트 코드에서도 과도한 중복은 피해야 합니다. 예를 들어, 테스트 환경 설정이나 공통적으로 사용되는 유틸리티 함수 등은 재사용성을 고려하여 DRY 원칙을 적용하는 것이 바람직합니다.

중요한 것은 균형입니다. 핵심 비즈니스 로직을 테스트하는 부분에서는 WET을 통해 가독성과 독립성을 확보하고, 공통적인 준비 과정 등에서는 DRY를 적용하여 효율성을 추구하는 것이죠.

---

마무리하며

이번 Apache 오픈소스 기여를 통해 단순히 코드를 작성하는 것을 넘어, 좋은 테스트 코드란 무엇인가에 대한 깊이 있는 고민을 할 수 있었습니다.

오픈소스 프로젝트는 단순한 코드 기여를 넘어, 시니어 개발자들의 경험과 지혜를 배울 수 있는 값진 기회임을 다시 한번 깨달았습니다. 앞으로도 이러한 배움을 통해 더 나은 개발자로 성장해 나가보겠습니다.