단위 테스트를 넘어서: Python의 Hypothesis를 이용한 속성 기반 테스트 심층 분석

소프트웨어 개발의 세계에서 테스팅은 품질의 초석입니다. 수십 년 동안 지배적인 패러다임은 예제 기반 테스팅이었습니다. 우리는 세심하게 입력을 만들고, 예상 출력을 정의하며, 코드가 계획대로 동작하는지 검증하기 위해 단언문(assertion)을 작성합니다. unittest나 pytest 같은 프레임워크에서 볼 수 있는 이 접근 방식은 강력하고 필수적입니다. 하지만 여러분이 생각지도 못했던 버그를 찾아낼 수 있는 보완적인 접근 방식이 있다고 한다면 어떨까요?

속성 기반 테스팅의 세계에 오신 것을 환영합니다. 이는 테스트의 초점을 특정 예제에서 코드의 일반적인 속성을 검증하는 것으로 옮기는 패러다임입니다. 그리고 파이썬 생태계에서 이 접근 방식의 독보적인 챔피언은 Hypothesis라는 라이브러리입니다.

이 포괄적인 가이드는 여러분을 완전한 초보자에서 Hypothesis를 사용한 속성 기반 테스팅의 자신감 있는 실무자로 이끌어 줄 것입니다. 우리는 핵심 개념을 탐색하고, 실제 예제를 깊이 파고들며, 이 강력한 도구를 일상적인 개발 워크플로우에 통합하여 더 견고하고, 신뢰할 수 있으며, 버그에 강한 소프트웨어를 구축하는 방법을 배울 것입니다.

속성 기반 테스트란 무엇인가? 사고의 전환

Hypothesis를 이해하기 위해서는 먼저 속성 기반 테스팅의 근본적인 아이디어를 파악해야 합니다. 우리 모두가 알고 있는 전통적인 예제 기반 테스팅과 비교해 보겠습니다.

예제 기반 테스트: 익숙한 방식

여러분이 직접 만든 정렬 함수 my_sort()를 작성했다고 상상해 봅시다. 예제 기반 테스팅에서는 여러분의 사고 과정은 다음과 같을 것입니다:

• "간단한 정렬된 리스트로 테스트해 보자." -> assert my_sort([1, 2, 3]) == [1, 2, 3]
• "역순으로 정렬된 리스트는 어떨까?" -> assert my_sort([3, 2, 1]) == [1, 2, 3]
• "빈 리스트는?" -> assert my_sort([]) == []
• "중복된 값이 있는 리스트는?" -> assert my_sort([5, 1, 5, 2]) == [1, 2, 5, 5]
• "그리고 음수가 있는 리스트는?" -> assert my_sort([-1, -5, 0]) == [-5, -1, 0]

이 방법은 효과적이지만, 근본적인 한계가 있습니다: 여러분이 생각할 수 있는 케이스만 테스트한다는 것입니다. 테스트는 여러분의 상상력만큼만 효과적입니다. 매우 큰 숫자, 부동 소수점 부정확성, 특정 유니코드 문자 또는 예상치 못한 동작을 유발하는 복잡한 데이터 조합과 관련된 엣지 케이스를 놓칠 수 있습니다.

속성 기반 테스트: 불변 속성으로 생각하기

속성 기반 테스팅은 판도를 바꿉니다. 특정 예제를 제공하는 대신, 여러분은 함수의 속성(properties) 또는 불변 속성(invariants)을 정의합니다. 즉, 모든 유효한 입력에 대해 참이어야 하는 규칙입니다. 우리의 my_sort() 함수에 대한 속성은 다음과 같을 수 있습니다:

• 출력은 정렬되어 있다: 임의의 숫자 리스트에 대해, 출력 리스트의 모든 요소는 그 뒤에 오는 요소보다 작거나 같습니다.
• 출력은 입력과 동일한 요소를 포함한다: 정렬된 리스트는 원래 리스트의 순열일 뿐이며, 요소가 추가되거나 손실되지 않습니다.
• 함수는 멱등성(idempotent)을 가진다: 이미 정렬된 리스트를 정렬해도 변하지 않아야 합니다. 즉, my_sort(my_sort(some_list)) == my_sort(some_list)입니다.

이 접근 방식을 사용하면, 여러분은 테스트 데이터를 작성하는 것이 아닙니다. 규칙을 작성하는 것입니다. 그런 다음 Hypothesis와 같은 프레임워크가 여러분의 속성이 틀렸음을 증명하기 위해 수백 또는 수천 개의 무작위적이고 다양하며 종종 교묘한 입력들을 생성하도록 합니다. 만약 속성을 깨뜨리는 입력을 발견하면, 그것은 버그를 찾은 것입니다.

Hypothesis 소개: 자동화된 테스트 데이터 생성기

Hypothesis는 파이썬을 위한 최고의 속성 기반 테스팅 라이브러리입니다. 여러분이 정의한 속성을 가져와 그것에 도전할 테스트 데이터를 생성하는 힘든 작업을 수행합니다. 이것은 단순한 무작위 데이터 생성기가 아니라, 효율적으로 버그를 찾도록 설계된 지능적이고 강력한 도구입니다.

Hypothesis의 주요 특징

• 자동 테스트 케이스 생성: 필요한 데이터의 *형태*를 정의하면 (예: "정수 리스트", "문자만 포함된 문자열", "미래의 datetime 객체"), Hypothesis는 그 형태에 맞는 매우 다양한 예제를 생성합니다.
• 지능적 축소(Intelligent Shrinking): 이것이 바로 마법 같은 기능입니다. Hypothesis가 실패하는 테스트 케이스를 찾았을 때(예: 정렬 함수를 다운시키는 50개의 복소수로 이루어진 리스트), 단순히 그 거대한 리스트를 보고하지 않습니다. 지능적이고 자동으로 입력을 단순화하여 실패를 유발하는 가능한 가장 작은 예제를 찾아냅니다. 50개 요소의 리스트 대신, 단지 [inf, nan]으로 인해 실패가 발생했다고 보고할 수 있습니다. 이는 디버깅을 믿을 수 없을 정도로 빠르고 효율적으로 만듭니다.
• 원활한 통합: Hypothesis는 pytest나 unittest와 같은 인기 있는 테스팅 프레임워크와 완벽하게 통합됩니다. 기존의 예제 기반 테스트와 함께 속성 기반 테스트를 추가하여 워크플로우를 변경할 필요가 없습니다.
• 풍부한 전략(Strategy) 라이브러리: 단순한 정수와 문자열부터 복잡하고 중첩된 데이터 구조, 시간대를 인식하는 datetime, 심지어 NumPy 배열에 이르기까지 모든 것을 생성하기 위한 방대한 내장 "전략" 모음이 함께 제공됩니다.
• 상태 기반 테스팅(Stateful Testing): 더 복잡한 시스템의 경우, Hypothesis는 일련의 동작을 테스트하여 상태 전이에서 버그를 찾을 수 있습니다. 이는 예제 기반 테스팅으로는 악명 높게 어려운 작업입니다.

시작하기: 첫 번째 Hypothesis 테스트

직접 한번 해봅시다. Hypothesis를 이해하는 가장 좋은 방법은 실제로 동작하는 것을 보는 것입니다.

설치

먼저 Hypothesis와 선호하는 테스트 러너(여기서는 pytest를 사용)를 설치해야 합니다. 간단합니다:

pip install pytest hypothesis

간단한 예제: 절댓값 함수

숫자의 절댓값을 계산하는 간단한 함수를 생각해 봅시다. 약간의 버그가 있는 구현은 다음과 같을 수 있습니다:

# `my_math.py` 파일
def custom_abs(x):
    """절댓값 함수의 커스텀 구현."""
    if x < 0:
        return -x
    return x

이제 테스트 파일 test_my_math.py를 작성해 봅시다. 먼저, 전통적인 pytest 접근 방식입니다:

# test_my_math.py (예제 기반)
def test_abs_positive():
    assert custom_abs(5) == 5

def test_abs_negative():
    assert custom_abs(-5) == 5

def test_abs_zero():
    assert custom_abs(0) == 0

이 테스트들은 통과합니다. 이 예제들을 기반으로 보면 우리 함수는 올바르게 보입니다. 하지만 이제 Hypothesis를 사용하여 속성 기반 테스트를 작성해 보겠습니다. 절댓값 함수의 핵심 속성은 무엇일까요? 결과는 절대 음수여서는 안 된다는 것입니다.

# test_my_math.py (Hypothesis를 이용한 속성 기반)
from hypothesis import given
from hypothesis import strategies as st

from my_math import custom_abs

@given(st.integers())
def test_abs_property_is_non_negative(x):
    """속성: 모든 정수의 절댓값은 항상 >= 0이다."""
    assert custom_abs(x) >= 0

하나씩 살펴보겠습니다:

• from hypothesis import given, strategies as st: 필요한 구성 요소를 가져옵니다. given은 일반 테스트 함수를 속성 기반 테스트로 바꾸는 데코레이터입니다. strategies는 데이터 생성기를 찾을 수 있는 모듈입니다.
• @given(st.integers()): 이것이 테스트의 핵심입니다. @given 데코레이터는 Hypothesis에게 이 테스트 함수를 여러 번 실행하도록 지시합니다. 각 실행마다 제공된 전략인 st.integers()를 사용하여 값을 생성하고, 이를 인수 x로 테스트 함수에 전달합니다.
• assert custom_abs(x) >= 0: 이것이 우리의 속성입니다. Hypothesis가 어떤 정수 x를 만들어내든, 우리 함수의 결과는 0보다 크거나 같아야 한다고 단언합니다.

pytest로 이것을 실행하면, 많은 값에 대해 통과할 것입니다. Hypothesis는 0, -1, 1, 큰 양수, 큰 음수 등을 시도할 것입니다. 우리의 간단한 함수는 이 모든 것을 올바르게 처리합니다. 이제, 약점을 찾을 수 있는지 다른 전략을 시도해 보겠습니다.

# 부동 소수점 숫자로 테스트해 보자
@given(st.floats())
def test_abs_floats_property(x):
    assert custom_abs(x) >= 0

이것을 실행하면, Hypothesis는 빠르게 실패하는 케이스를 찾을 것입니다!

Falsifying example: test_abs_floats_property(x=nan)
... 
assert custom_abs(nan) >= 0
AssertionError: assert nan >= 0

Hypothesis는 우리 함수가 float('nan')(숫자가 아님)을 입력받았을 때 nan을 반환한다는 것을 발견했습니다. nan >= 0이라는 단언문은 거짓입니다. 우리는 수동으로 테스트할 생각을 거의 하지 않았을 미묘한 버그를 방금 찾았습니다. 이 경우를 처리하도록 함수를 수정할 수 있습니다. 예를 들어 ValueError를 발생시키거나 특정 값을 반환하도록 말이죠.

더 좋은 점은, 만약 버그가 매우 특정한 부동 소수점에서 발생했다면 어땠을까요? Hypothesis의 축소(shrinker) 기능은 크고 복잡한 실패 숫자를 가져와서 여전히 버그를 유발하는 가장 간단한 버전으로 줄여주었을 것입니다.

전략의 힘: 테스트 데이터 만들기

전략(Strategies)은 Hypothesis의 핵심입니다. 그것들은 데이터를 생성하기 위한 레시피입니다. 라이브러리에는 방대한 종류의 내장 전략이 포함되어 있으며, 여러분은 그것들을 결합하고 사용자 정의하여 상상할 수 있는 거의 모든 데이터 구조를 생성할 수 있습니다.

일반적인 내장 전략

• 숫자형:
  • st.integers(min_value=0, max_value=1000): 정수를 생성하며, 선택적으로 특정 범위 내에서 생성합니다.
  • st.floats(min_value=0.0, max_value=1.0, allow_nan=False, allow_infinity=False): 부동 소수점을 생성하며, 특수 값에 대한 세밀한 제어가 가능합니다.
  • st.fractions(), st.decimals()
• 텍스트:
  • st.text(min_size=1, max_size=50): 특정 길이의 유니코드 문자열을 생성합니다.
  • st.text(alphabet='abcdef0123456789'): 특정 문자 집합으로 문자열을 생성합니다(예: 16진수 코드).
  • st.characters(): 개별 문자를 생성합니다.
• 컬렉션:
  • st.lists(st.integers(), min_size=1): 각 요소가 정수인 리스트를 생성합니다. 인수로 다른 전략을 전달하는 것을 주목하세요! 이것을 조합(composition)이라고 합니다.
  • st.tuples(st.text(), st.booleans()): 고정된 구조의 튜플을 생성합니다.
  • st.sets(st.integers())
  • st.dictionaries(keys=st.text(), values=st.integers()): 지정된 키와 값 유형을 가진 딕셔너리를 생성합니다.
• 시간 관련:
  • st.dates(), st.times(), st.datetimes(), st.timedeltas(). 이들은 시간대를 인식하도록 만들 수 있습니다.
• 기타:
  • st.booleans(): True 또는 False를 생성합니다.
  • st.just('constant_value'): 항상 동일한 단일 값을 생성합니다. 복잡한 전략을 조합할 때 유용합니다.
  • st.one_of(st.integers(), st.text()): 제공된 전략 중 하나에서 값을 생성합니다.
  • st.none(): 오직 None만 생성합니다.

전략의 결합과 변환

Hypothesis의 진정한 힘은 더 간단한 전략들로부터 복잡한 전략을 구축하는 능력에서 나옵니다.

.map() 사용하기

.map() 메서드를 사용하면 한 전략의 값을 가져와 다른 것으로 변환할 수 있습니다. 이것은 사용자 정의 클래스의 객체를 생성하는 데 완벽합니다.

# 간단한 데이터 클래스
from dataclasses import dataclass

@dataclass
class User:
    user_id: int
    username: str

# User 객체를 생성하는 전략
user_strategy = st.builds(
    User,
    user_id=st.integers(min_value=1),
    username=st.text(min_size=3, alphabet='abcdefghijklmnopqrstuvwxyz')
)

@given(user=user_strategy)
def test_user_creation(user):
    assert isinstance(user, User)
    assert user.user_id > 0
    assert user.username.isalpha()

.filter()와 assume() 사용하기

때로는 생성된 특정 값을 거부해야 할 필요가 있습니다. 예를 들어, 합이 0이 아닌 정수 리스트가 필요할 수 있습니다. .filter()를 사용할 수 있습니다:

st.lists(st.integers()).filter(lambda x: sum(x) != 0)

하지만 .filter()를 사용하는 것은 비효율적일 수 있습니다. 만약 조건이 자주 거짓이라면, Hypothesis는 유효한 예제를 생성하는 데 오랜 시간을 소비할 수 있습니다. 더 나은 접근 방식은 종종 테스트 함수 내에서 assume()을 사용하는 것입니다:

from hypothesis import assume

@given(st.lists(st.integers()))
def test_something_with_non_zero_sum_list(numbers):
    assume(sum(numbers) != 0)
    # ... 여기에 테스트 로직을 작성합니다 ...

assume()은 Hypothesis에게 "이 조건이 충족되지 않으면, 이 예제는 그냥 버리고 새로운 것을 시도해."라고 말합니다. 이것은 테스트 데이터를 제약하는 더 직접적이고 종종 더 성능이 좋은 방법입니다.

st.composite() 사용하기

하나의 생성된 값이 다른 값에 의존하는 정말 복잡한 데이터 생성을 위해서는 st.composite()이 필요한 도구입니다. 이것은 특별한 draw 함수를 인수로 받는 함수를 작성할 수 있게 해주며, 이 함수를 사용하여 다른 전략들로부터 단계별로 값을 가져올 수 있습니다.

고전적인 예는 리스트와 그 리스트에 대한 유효한 인덱스를 생성하는 것입니다.

@st.composite
def list_and_index(draw):
    # 먼저, 비어있지 않은 리스트를 뽑습니다
    my_list = draw(st.lists(st.integers(), min_size=1))
    # 그런 다음, 그 리스트에 대해 유효성이 보장되는 인덱스를 뽑습니다
    index = draw(st.integers(min_value=0, max_value=len(my_list) - 1))
    return (my_list, index)

@given(data=list_and_index())
def test_list_access(data):
    my_list, index = data
    # 이 접근은 전략을 구축한 방식 덕분에 안전함이 보장됩니다
    element = my_list[index]
    assert element is not None # 간단한 단언문

실전에서의 Hypothesis: 실제 시나리오

이러한 개념들을 소프트웨어 개발자들이 매일 마주하는 더 현실적인 문제에 적용해 봅시다.

시나리오 1: 데이터 직렬화 함수 테스트

사용자 프로필(딕셔너리)을 URL에 안전한 문자열로 직렬화하고, 그것을 다시 역직렬화하는 함수가 있다고 상상해 봅시다. 핵심 속성은 그 과정이 완벽하게 가역적이어야 한다는 것입니다.

import json
import base64

def serialize_profile(data: dict) -> str:
    """딕셔너리를 URL-safe base64 문자열로 직렬화합니다."""
    json_string = json.dumps(data)
    return base64.urlsafe_b64encode(json_string.encode('utf-8')).decode('utf-8')

def deserialize_profile(encoded_str: str) -> dict:
    """문자열을 다시 딕셔너리로 역직렬화합니다."""
    json_string = base64.urlsafe_b64decode(encoded_str.encode('utf-8')).decode('utf-8')
    return json.loads(json_string)

# 이제 테스트 차례입니다
# JSON 호환 딕셔너리를 생성하는 전략이 필요합니다
json_dictionaries = st.dictionaries(
    keys=st.text(),
    values=st.recursive(st.none() | st.booleans() | st.floats(allow_nan=False) | st.text(),
                      lambda children: st.lists(children) | st.dictionaries(st.text(), children),
                      max_leaves=10)
)

@given(profile=json_dictionaries)
def test_serialization_roundtrip(profile):
    """속성: 인코딩된 프로필을 역직렬화하면 원래 프로필이 반환되어야 합니다."""
    encoded = serialize_profile(profile)
    decoded = deserialize_profile(encoded)
    assert profile == decoded

이 단 하나의 테스트는 우리 함수들을 빈 딕셔너리, 중첩된 리스트가 있는 딕셔너리, 유니코드 문자가 있는 딕셔너리, 이상한 키를 가진 딕셔너리 등 엄청나게 다양한 데이터로 시험할 것입니다. 이것은 몇 개의 수동 예제를 작성하는 것보다 훨씬 더 철저합니다.

시나리오 2: 정렬 알고리즘 테스트

정렬 예제로 다시 돌아가 봅시다. 이전에 정의했던 속성들을 테스트하는 방법은 다음과 같습니다.

from collections import Counter

def my_buggy_sort(numbers):
    # 미묘한 버그를 넣어봅시다: 중복된 값을 제거합니다
    return sorted(list(set(numbers)))

@given(st.lists(st.integers()))
def test_sorting_properties(numbers):
    sorted_list = my_buggy_sort(numbers)

    # 속성 1: 출력은 정렬되어 있다
    for i in range(len(sorted_list) - 1):
        assert sorted_list[i] <= sorted_list[i+1]

    # 속성 2: 요소들이 동일하다 (이것이 버그를 찾을 것입니다)
    assert Counter(numbers) == Counter(sorted_list)

    # 속성 3: 함수는 멱등성을 가진다
    assert my_buggy_sort(sorted_list) == sorted_list

이 테스트를 실행하면, Hypothesis는 속성 2에 대해 numbers=[0, 0]과 같은 실패 예제를 빠르게 찾을 것입니다. 우리 함수는 [0]을 반환하고, Counter([0, 0])은 Counter([0])과 같지 않습니다. 축소 기능은 실패 예제를 가능한 한 간단하게 만들어 버그의 원인을 즉시 명확하게 보여줄 것입니다.

시나리오 3: 상태 기반 테스팅

시간이 지남에 따라 내부 상태가 변하는 객체(데이터베이스 연결, 쇼핑 카트, 캐시 등)의 경우 버그를 찾는 것이 매우 어려울 수 있습니다. 오류를 유발하기 위해 특정 순서의 작업이 필요할 수 있습니다. Hypothesis는 바로 이 목적을 위해 `RuleBasedStateMachine`을 제공합니다.

인메모리 키-값 저장소에 대한 간단한 API를 상상해 보세요:

class SimpleKeyValueStore:
    def __init__(self):
        self._data = {}
    def set(self, key, value):
        self._data[key] = value
    def get(self, key):
        return self._data.get(key)
    def delete(self, key):
        if key in self._data:
            del self._data[key]
    def size(self):
        return len(self._data)

우리는 그것의 동작을 모델링하고 상태 머신으로 테스트할 수 있습니다:

from hypothesis.stateful import RuleBasedStateMachine, rule, Bundle

class KeyValueStoreMachine(RuleBasedStateMachine):
    def __init__(self):
        super().__init__()
        self.model = {}
        self.sut = SimpleKeyValueStore()

    # Bundle()은 규칙 간에 데이터를 전달하는 데 사용됩니다
    keys = Bundle('keys')

    @rule(target=keys, key=st.text(), value=st.integers())
    def set_key(self, key, value):
        self.model[key] = value
        self.sut.set(key, value)
        return key

    @rule(key=keys)
    def delete_key(self, key):
        del self.model[key]
        self.sut.delete(key)

    @rule(key=st.text())
    def get_key(self, key):
        model_val = self.model.get(key)
        sut_val = self.sut.get(key)
        assert model_val == sut_val

    @rule()
    def check_size(self):
        assert len(self.model) == self.sut.size()

# 테스트를 실행하려면, 머신과 unittest.TestCase를 상속받기만 하면 됩니다
# pytest에서는, 테스트를 머신 클래스에 할당하기만 하면 됩니다
TestKeyValueStore = KeyValueStoreMachine.TestCase

이제 Hypothesis는 `set_key`, `delete_key`, `get_key`, `check_size` 작업의 무작위 시퀀스를 실행하며, 단언문 중 하나가 실패하게 만드는 시퀀스를 끊임없이 찾으려고 시도할 것입니다. 삭제된 키를 가져오는 것이 올바르게 동작하는지, 여러 번의 설정과 삭제 후에도 크기가 일관되는지, 그리고 수동으로 테스트할 생각을 하지 못할 수 있는 많은 다른 시나리오들을 확인할 것입니다.

모범 사례 및 고급 팁

• 예제 데이터베이스: Hypothesis는 똑똑합니다. 버그를 찾으면 실패한 예제를 로컬 디렉토리(.hypothesis/)에 저장합니다. 다음에 테스트를 실행할 때, 그 실패한 예제를 먼저 재생하여 버그가 여전히 존재한다는 즉각적인 피드백을 줍니다. 버그를 수정하면, 그 예제는 더 이상 재생되지 않습니다.
• @settings로 테스트 실행 제어하기: @settings 데코레이터를 사용하여 테스트 실행의 많은 측면을 제어할 수 있습니다. 예제의 수를 늘리거나, 단일 예제가 실행될 수 있는 시간 제한(무한 루프를 잡기 위해)을 설정하고, 특정 상태 검사를 끌 수 있습니다.

  @settings(max_examples=500, deadline=1000) # 500개의 예제 실행, 1초 시간 제한
  @given(...) ...

• 실패 재현하기: 모든 Hypothesis 실행은 시드 값(예: @reproduce_failure('version', 'seed'))을 출력합니다. 만약 CI 서버가 로컬에서 재현할 수 없는 버그를 발견하면, 제공된 시드와 함께 이 데코레이터를 사용하여 Hypothesis가 정확히 동일한 예제 시퀀스를 실행하도록 강제할 수 있습니다.
• CI/CD와 통합하기: Hypothesis는 모든 지속적인 통합 파이프라인에 완벽하게 적합합니다. 프로덕션에 도달하기 전에 모호한 버그를 찾는 능력은 매우 귀중한 안전망이 됩니다.

사고의 전환: 속성으로 생각하기

Hypothesis를 채택하는 것은 새로운 라이브러리를 배우는 것 이상입니다. 그것은 코드의 정확성에 대해 새로운 방식으로 생각하는 것을 받아들이는 것입니다. "어떤 입력을 테스트해야 할까?"라고 묻는 대신, "이 코드에 대한 보편적인 진리는 무엇인가?"라고 묻기 시작합니다.

속성을 식별하려고 할 때 도움이 될 몇 가지 질문은 다음과 같습니다:

• 역연산이 있는가? (예: 직렬화/역직렬화, 암호화/복호화, 압축/압축 해제). 속성은 연산과 그 역연산을 수행하면 원래 입력을 얻어야 한다는 것입니다.
• 연산이 멱등성을 가지는가? (예: abs(abs(x)) == abs(x)). 함수를 한 번 이상 적용해도 한 번 적용한 것과 동일한 결과가 나와야 합니다.
• 동일한 결과를 계산하는 다른, 더 간단한 방법이 있는가? 복잡하고 최적화된 함수가 간단하고 명백하게 올바른 버전과 동일한 출력을 생성하는지 테스트할 수 있습니다(예: 여러분의 멋진 정렬을 파이썬의 내장 sorted()와 비교 테스트).
• 출력에 대해 항상 참이어야 하는 것은 무엇인가? (예: `find_prime_factors` 함수의 출력은 소수만 포함해야 하며, 그들의 곱은 입력과 같아야 합니다).
• 상태는 어떻게 변하는가? (상태 기반 테스팅의 경우) 유효한 작업 후에 어떤 불변 속성이 유지되어야 하는가? (예: 쇼핑 카트의 항목 수는 절대 음수가 될 수 없다).

결론: 새로운 차원의 자신감

Hypothesis를 사용한 속성 기반 테스팅은 예제 기반 테스팅을 대체하지 않습니다. 중요한 비즈니스 로직과 잘 이해된 요구사항(예: "X 국가의 사용자는 Y 가격을 보아야 한다")에 대해서는 여전히 특정하고 수동으로 작성된 테스트가 필요합니다.

Hypothesis가 제공하는 것은 코드의 동작을 탐색하고 예측하지 못한 엣지 케이스로부터 보호하는 강력하고 자동화된 방법입니다. 그것은 지치지 않는 파트너 역할을 하며, 인간이 현실적으로 작성할 수 있는 것보다 더 다양하고 교묘한 수천 개의 테스트를 생성합니다. 코드의 근본적인 속성을 정의함으로써, 여러분은 Hypothesis가 테스트할 수 있는 견고한 명세를 만들고, 소프트웨어에 대한 새로운 차원의 자신감을 얻게 됩니다.

다음에 함수를 작성할 때, 잠시 시간을 내어 예제를 넘어서 생각해 보세요. 스스로에게 물어보세요, "규칙은 무엇인가? 항상 참이어야 하는 것은 무엇인가?" 그런 다음, Hypothesis가 그것들을 깨뜨리려는 힘든 작업을 하도록 하세요. 그것이 찾아내는 것에 놀라게 될 것이고, 여러분의 코드는 그것으로 인해 더 좋아질 것입니다.