테스트 코드의 DRY 원칙 적용에 대한 오해
DRY 원칙은 지식이나 행위의 중복이 불일치를 초래할 때 유효합니다. 그러나 테스트 코드는 애플리케이션 코드와 달리 ‘임의적(arbitrary)’이라는 특성을 가집니다. 테스트는 애플리케이션의 ‘명세(specification)’ 역할을 하지만, 테스트 자체는 다른 제약에 묶이지 않습니다. 따라서 테스트 코드의 동일한 두 부분이 반드시 ‘중복’으로 간주되지 않으며, 한쪽이 변경되어도 버그로 이어지지 않을 수 있습니다. 테스트 헬퍼 코드에는 애플리케이션 코드와 동일한 DRY 원칙이 적용됩니다.
RSpec Shared Examples의 문제점
Shared examples는 let! 및 uri 정의 후 it_behaves_like를 호출하는 방식이 전역 변수를 설정하고 이를 사용하는 함수를 호출하는 것과 유사하게 작동합니다. 이는 다음과 같은 문제점을 야기합니다:
-
넓은 스코프와 낮은 예측 가능성: 전역 변수처럼 스코프가 넓어 정의된 곳에서 사용처를 파악하기 어렵고, 사용처에서 정의를 알기 어려워 변경의 안전성을 예측하기 어렵습니다. 이는 캡슐화와 상반됩니다.
-
낮은 가독성과 유지보수성:
it_behaves_like 'a normal dog'와 같이 문자열로 동작을 호출하는 방식은 해당 shared example의 정의를 찾기 어렵게 만들어 유지보수를 더욱 복잡하게 합니다.
테스트 중복과 효율성
테스트의 목표는 100% 커버리지 자체가 아닌 실질적인 이점 확보입니다. 여러 기능이 유사한 동작을 공유할 때, 모든 케이스를 테스트하기보다 ‘대표적인 샘플’을 테스트하는 것이 효율적일 수 있습니다. 첫 테스트에서 얻는 이점은 크지만, 유사한 코드를 커버하는 추가 테스트에서 얻는 이점은 점차 감소합니다.
Shared Examples의 대안
테스트 내 CSS 셀렉터와 같은 중복을 줄이고 가독성을 높이기 위해 Page Object 패턴을 활용할 수 있습니다. Page Object는 테스트의 추상화 수준을 높여 더 적은 코드로 동일한 목적을 달성하게 하며, shared examples처럼 의미를 모호하게 만들지 않으면서 중복 코드를 줄이는 긍정적인 효과를 가져옵니다.