기술 요약: 예외적 동작(Exceptional Behaviors): 얼마나 자주 테스트되는가?

문제 정의

예외(Exception)는 드물게 발생하는 것으로 예상되는 에러 케이스를 처리하기 위해 사용되는 근본적인 프로그래밍 구조로, 개발자가 과도한 if/else 체크로 코드를 복잡하게 만드는 것을 방지해 줍니다. 기존 연구와 모범 사례들은 고품질 테스트 스위트가 회귀(regression)를 방지하고 버그를 포착하기 위해 정상 동작과 예외적 동작을 모두 커버해야 한다고 제안하지만, 실증적 증거에 따르면 개발자들은 주로 정상적인("happy path") 동작을 테스트하는 경향이 있습니다.

현재 문헌에는 중요한 공백이 존재합니다. 이전 연구들은 거의 전적으로 예외적 테스트(exceptional tests)—즉, 예외가 테스트 레벨까지 전파되어 명시적으로 단언(assert)되는 테스트(예: assertRaises 사용)—에만 집중해 왔습니다. 이러한 연구들은 코드가 테스트로 전달되기 전에 (via try/except 블록을 통해) 내부적으로 발생하고 포착되어 처리되는 예외를 고려하지 않습니다. 결과적으로, 예외가 테스트 하네스(test harness)로 전파되지 않는 경우를 포함하여, 실제 시스템에서 예외적 동작이 실제로 얼마나 빈번하게 실행되는지는 불분명한 상태로 남아 있습니다. 또한, 런타임에서 예외가 발생하는 빈도—드문 발생부터 예외가 일반적인 동작이 되는 경우까지—에 대한 깊이 있는 탐구도 이루어지지 않았습니다.

연구 방법론

저자들은 25개의 실제 Python 시스템의 테스트 스위트를 분석하는 실증 연구를 수행했습니다. 데이터셋은 인기 있는 서드파티 라이브러리(예: Flask, Requests, Pylint)와 표준 라이브러리 모듈(예: email, pathlib, argparse)을 혼합하여 구성되었으며, 5,372개의 실행된 메서드, 1,790만 번의 메서드 호출, 140만 건의 발생한 예외를 포함합니다.

연구는 다음과 같은 방법론을 사용했습니다:

1. 계측(Instrumentation): 저자들은 Python의 sys.settrace 함수를 기반으로 구축된 동적 분석 도구인 SpotFlow를 활용했습니다. 이 도구는 메서드 레벨에서 실행을 모니터링하기 위해 테스트 스위트를 계측합니다.
2. 데이터 수집: 테스트 실행 중, 계측된 시스템은 다음을 기록했습니다:
   • 실행된 메서드.
   • 특정 메서드가 런타임에 예외를 발생시켰는지 여부.
   • 각 메서드의 총 호출 횟수.
   • 예외를 발생시킨 호출(exception-raising calls)의 횟수.
3. 분석: 수집된 데이터는 세 가지 연구 질문(RQ)을 중심으로 서로 다른 입도(granularity)에 따라 분석되었습니다:
   • RQ1 (메서드 레벨): 얼마나 많은 메서드가 런타임에 예외를 발생시키는가?
   • RQ2 (호출 레벨): 예외를 발생시키는 메서드의 호출이 실제로 예외로 이어지는 빈도는 어느 정도인가?
   • RQ3 (시스템 레벨): 예외를 발생시키는 메서드와 호출이 서로 다른 시스템 간에 어떻게 달라지는가?

주요 결과

RQ1: 예외 발생 메서드의 보편성

• 실행된 메서드의 21.4%(5,372개 중 1,150개)가 테스트 실행 중 적어도 하나 이상의 예외를 발생시켰습니다.
• 나머지 **78.6%**는 예외가 발생하지 않는 메서드였습니다.
• 예외 발생 메서드는 예외가 없는 메서드보다 더 복잡하고 더 많이 실행되는 경향을 보였습니다. 중앙값 기준으로, 예외 발생 메서드는 예외가 없는 메서드보다 4배 더 많은 호출을 받았고 3배 더 많은 경로를 실행했습니다.
• 연구에서는 200개의 고유한 예외 유형을 식별했습니다. 대부분은 일반적인 유형(예: ValueError, TypeError)이었으나, 특정 예외는 종종 단일 메서드에 의해 발생했습니다.

RQ2: 예외 발생 빈도

• 예외를 발생시키는 메서드 내에서, 예외 발생 호출의 중앙값 빈도는 10%(10번 호출 중 1번)입니다.
• 예외 발생 빈도의 분포는 매우 왜곡되어 있습니다:
  • 희소함 (≤10%): 예외 발생 메서드의 50%가 여기에 해당합니다.
  • 간헐적 (>10% ~ ≤50%): 28.4%의 메서드.
  • 흔함 (>50% ~ <90%): 9.6%의 메서드.
  • 거의 항상 (≥90%): 11.8%의 메서드.
• 관찰 사항: 예외를 발생시키는 메서드의 약 **80%**는 예외를 드물게 발생시킵니다. 그러나 상당한 소수(약 20%)는 예외를 빈번하게 발생시키며, 특정 Pylint 메서드와 같은 경우에는 예외를 발생시키는 것이 기대되는 또는 "정상적인" 동작(100%의 호출에서 발생)입니다.

RQ3: 시스템별 차이

• 25개 시스템 중 22개가 예외 발생 메서드보다 예외가 없는 메서드를 더 많이 포함하고 있습니다.
• 25개 시스템 중 19개는 메서드당 예외 발생 호출의 중앙값 비율이 30% 미만입니다.
• 시스템 간의 변동성이 큽니다. 예를 들어, csv 라이브러리는 53.3%의 예외 발생 메서드를 가진 반면, Error Corrector는 5.6%에 불과했습니다.

의의 및 시사점

본 논문은 로컬에서 처리되는 예외를 무시함으로써 현재의 예외적 동작 테스트에 대한 이해가 불완전하다고 주장합니다. 연구 결과는 예외 발생이 항상 "비정상적"이거나 드문 사건이라는 가설에 도전합니다.

저자들은 연구자와 실무자를 위해 세 가지 주요 시사점을 제안합니다:

1. 새로운 테스트 도구의 개발:
   대부분의 예외 발생 메서드는 드물게 실행되므로(종종 10% 미만), 기존 테스트 스위트는 예외 처리 코드를 테스트하지 못한 채 남겨둘 가능성이 큽니다. 저자들은 예외가 로컬에서 포착되어 테스트로 전파되지 않는 경우를 포함하여, 예외적 케이스를 커버하는 테스트를 식별할 수 있는 도구를 개발할 것을 제안합니다. 이러한 도구는 개발자에게 에러 핸들링 로직의 누락된 커버리지를 경고할 수 있습니다.

2. "비정상적" 동작의 재평가:
   본 연구는 예외 발생이 반드시 "비정상적"인 것은 아님을 강조합니다. 특정 메서드(예: "거의 항상" 카테고리에 속하는 메서드)의 경우, 예외를 발생시키는 것이 표준 제어 흐름의 일부입니다. 예외적 동작을 연구하는 연구자들은 예외가 버그/엣지 케이스를 나타내는 메서드와 예외가 기대되는 결과인 메서드를 구분해야 합니다. 이 구분을 하지 못하면 테스트 품질이나 버그 탐지에 대해 잘못된 평가를 내릴 수 있습니다.

3. 비용이 많이 드는 try/except 블록의 리팩토링:
   저자들은 Python의 EAFP(Easier to Ask for Forgiveness than Permission) 코딩 스타일이 종종 try/except 블록으로 이어진다는 점에 주목합니다. 예외가 드물 때는 효율적이지만, 예외를 포착하는 작업은 계산 비용이 많이 듭니다. 본 연구는 예외를 빈번하게 발생시키는 메서드(예: 90% 이상의 호출에서 KeyError 또는 AttributeError가 발생하는 경우)를 성능 개선을 위한 강력한 리팩토링 후보로 식별합니다. 이를 명시적인 체크(예: if key in dict)로 교체하면 성능을 크게 향상시킬 수 있습니다.

결론

이 실증 연구는 로컬에서 처리되는 예외를 모두 고려하여, 실제 Python 시스템에서 예외적 동작이 얼마나 자주 테스트되는지에 대한 첫 번째 종합적인 관점을 제공합니다. 결과에 따르면 대부분의 예외 발생 메서드는 드물게 실행되지만, 코드베이스의 상당 부분은 예외를 빈번한 제어 메커니즘으로 사용하고 있습니다. 저자들은 이러한 동작을 지원하기 위한 더 나은 도구가 필요하며, 예외가 너무 자주 발생하는 코드 패턴을 리팩토링함으로써 성능 최적화를 달els 수 있다고 결론짓습니다.