Test Behaviors, Not Methods! Detecting Tests Obsessed by Methods
이 논문은 단일 프로덕션 메서드의 여러 실행 경로를 커버하는 테스트를 식별하는 "메서드에 집착하는 테스트(Test Obsessed by Method)"라는 새로운 테스트 스멜을 제안하며, 파이썬 표준 라이브러리에 대한 실증적 연구를 통해 이러한 테스트들이 종종 여러 동작을 검증하고 더 집중된 단위로 리팩터링될 수 있음을 입증한다.
원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
당신이 미식가인 비평가를 위해 테이스팅 메뉴를 준비하는 셰프라고 상상해 보십시오. 훌륭한 요리의 황금률은 다음과 같습니다: 한 접시에 하나의 뚜렷한 맛만을 담아내는 것. 만약 스테이크 한 조각, 케이크 한 조각, 그리고 아이스크림 한 스쿱을 한데 섞어 하나의 접시에 담아낸다면, 비평가는 혼란에 빠질 것입니다. 스테이크가 덜 익은 것인지, 케이크가 너무 단 것인지, 아니면 아이스크림이 녹고 있는 것인지 알 수 없기 때문입니다. 무언가 잘못되었을 때, 그들은 식사의 어느 부분에 책임을 물어야 할지 알 수 없게 됩니다.
소프트웨어의 세계에서 '요리'는 테스트이며, '맛'은 동작(소프트웨어가 수행해야 하는 일)입니다.
*"Test Behaviors, Not Methods!"(메서드가 아닌 테스트 동작을 테스트하라!)*라는 제목의 이 논문은 현재 많은 소프트웨어 테스트가 이처럼 뒤섞인 접시처럼 제공되고 있다고 주장합니다. 저자인 안드레 호라(Andre Hora)와 앤디 자이드만(Andy Zaidman)은 이러한 혼란스러운 테스트를 찾아내는 새로운 방법, 즉 그들이 **"메서드에 집착하는 테스트(Tests Obsessed by Methods)"**라고 부르는 개념을 소개합니다.
이 발견을 쉬운 비유를 통해 정리하면 다음과 같습니다:
1. 옛 방식: 재료의 개수 세기
이전에는 전문가들이 이 지저킨 테스트들을 찾기 위해 단순히 테스트가 코드를 몇 번이나 "건드렸는지" 횟수를 셌습니다. 그들은 "만약 테스트가 프로덕션 코드를 3번 이상 호출한다면, 아마도 너무 많은 일을 하고 있을 것이다"라고 생각했습니다.
저자들은 이를 "성급한 테스트(Eager Test)" 냄새라고 부릅니다. 하지만 이 방법은 음식을 판단할 때 사용된 숟가락의 개수만 세는 것과 같다고 말합니다. 이는 부정확합니다. 어떤 테스트는 실제로 다른 맛을 테스트하기 위해서가 아니라, 단지 장면을 설정하기 위해 함수를 여러 번 호출할 수도 있기 때문입니다. 이는 문제를 찾는 매우 서툰 방식입니다.
2. 새로운 아이디어: 영화 관람하기 (런타임 분석)
단순히 숟가락의 개수를 세는 대신, 저자들은 테스트가 진행되는 과정을 영화처럼 관찰할 것을 제안합니다. 그들은 새로운 규칙을 제시합니다: 만약 단 하나의 테스트가 결승선에 도달하기 위해 코드의 여러 가지 서로 다른 "경로(paths)"를 강제로 타게 만든다면, 그 테스트는 "집착"하고 있는 것이다.
프로덕션 메서드(코드의 한 조각)를 하나의 미로라고 생각해 보십시오.
- 좋은 테스트: 당신은 왼쪽 문이 제대로 작동하는지 확인하기 위해 탐험가 한 명을 미로로 보냅니다. 그다음, 오른쪽 문이 작동하는지 확인하기 위해 두 번째 탐험가를 보냅니다. 명확하고 집중되어 있습니다.
- 집착하는 테스트: 당신은 한 명의 탐험가를 보내 왼쪽 문을 통과하게 한 뒤, 다시 되돌아오게 하고, 다시 오른쪽 문을 통과하게 한 다음, 마지막으로 비밀 통로까지 시도하게 합니다. 이 모든 것을 한 번에 수행합니다.
저자들은 이를 **"메서드에 집착하는 테스트(Test Obsessed by Method)"**라고 부릅니다. 이 테스트는 하나의 미로 안에 있는 모든 가능한 경로를 한꺼번에 확인하려 하기 때문에 "탐욕스럽다"고 볼 수 있습니다.
3. 실험: 파이썬 라이브러리 점검
이 "집착"이 실제 문제인지 확인하기 위해, 저자들은 파이썬 표준 라이브러리(수백만 명의 개발자가 사용하는 방대한 양의 사전 작성된 코드 모음)를 뒤지는 보물 찾기를 떠났습니다.
그들은 2,054개의 테스트를 조사했습니다. 결과는 다음과 같습니다:
- 추적: 그들은 44개의 "집착하는" 테스트를 발견했습니다. 이 테스트들은 단 하나의 함수에서 발생하는 여러 가지 서로 다른 결과들을 한 번에 확인하려고 시도하고 있었습니다.
- 확산: 이 지저분한 테스트들은 그들이 점검한 12개의 라이브러리 중 11개에서 발견되었습니다. 이것은 드문 오류가 아니라 흔한 습관입니다.
- 해결책: 이 44개의 지저분한 테스트들은 평균적으로 실제로 두 가지의 서로 다른 일을 하려고 시도하고 있었습니다. 만약 이들을 분리한다면, 이 44개의 테스트는 118개의 깨끗하고 집중된 테스트가 될 수 있습니다.
- "아하!" 모먼트: 이 지저분한 테스트 중 약 **23%**에서는 프로그래머들이 실제로 "이봐, 우리는 여기서 두 가지 서로 다른 것을 테스트하고 있어!"라고 인정하는 주석을 작성해 두었습니다. 그들도 이것이 지저분하다는 것을 알고 있었지만 그대로 진행한 것입니다.
4. 이것이 왜 중요한가?
저자들은 테스트가 한 번에 너무 많은 경로를 덮으려고 할 때 다음과 같은 문제가 발생한다고 주장합니다:
- 이해하기 어렵다: 그 섞인 접시처럼, 당신은 어떤 맛을 느껴야 할지 알 수 없습니다.
- 취약하다: 만약 "왼쪽 문"에 대한 코드를 변경한다면, 두 기능이 서로 관련이 없음에도 불구하고 실수로 "오른가 문"에 대한 테스트까지 망가뜨릴 수 있습니다.
- 수정하기 어렵다: 테스트가 실패했을 때, 어떤 구체적인 동작이 고장 났는지 알 수 없습니다.
결론
이 논문은 모든 테스트 문제를 해결하겠다고 주장하는 것이 아닙니다. 대신, 단순히 횟수를 세는 것보다 더 날카로운 도구(런타임 분석 사용)를 사용하여, 하나의 코드 조각으로 너무 많은 일을 하려는 테스트를 찾아내는 방법을 제시합니다.
저자들은 만약 하나의 테스트가 함수로 하여금 여러 가지 다른 경로를 타도록 강제한다면, 그 테스트를 분리해야 한다고 제안합니다. 셰프가 스테이크, 케이크, 아이스크림을 각각 별도의 접시에 담아 내놓아야 하는 것처럼, 개발자도 모든 뚜렷한 동작에 대해 별도의 테스트를 작성해야 합니다.
요약하자면: 테스트에 욕심을 부리지 마십시오. 한 번에 하나의 동작, 하나의 경로, 하나의 맛만을 테스트하십시오.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.