🧪 내가 보려고 작성한 pytest 가이드

원본 게시글: https://velog.io/@euisuk-chung/내가-보려고-작성한-pytest-가이드

https://youtu.be/cHYq1MRoyI0

본 포스팅은 아래 자료들을 참고해서 작성되었습니다.

• Pytest Tutorial – How to Test Python Code
• pytest documentation

TL;DR 📝

• pytest란?
  • pytest는 파이썬 대표 테스트 프레임워크
  • 파일/함수 네이밍만 지켜도 자동으로 테스트 탐지(autodiscovery)
  • 단순 assert 문으로도 풍부한 실패 리포트 제공 (Rich Assertion Introspection)
  • Fixture/Parametrize/Markers 등으로 재사용성·유연성 ↑

• 핵심 테스트 유형
  • 유닛 테스트: 작은 함수/메서드의 정확성 검증
  • 경계값 테스트: 임계치·엣지 입력에서 안정성 확인
  • 예외 처리: 잘못된 입력 → 명시적 에러 발생 여부 확인
  • 픽스처: 반복되는 준비/정리 로직 분리
  • 마커: slow, skip, xfail 태깅으로 실행 제어
  • 파라미터화: 다양한 입력/출력 케이스를 한 번에 검증
  • 모킹(Mock): 외부 API/DB 의존성 제거, 가짜 객체로 격리

• 실용 포인트
  • IDE(Pycharm, VSCode)에서 바로 실행 버튼 제공
  • unittest/nose 호환 → 기존 코드도 pytest로 돌릴 수 있음
  • 수많은 플러그인(Django, Pandas 등)으로 확장성 풍부

• AI 활용
  • ChatGPT 같은 LLM에게 코드 붙여넣고 “pytest 스타일로 테스트 작성해줘”
    → 테스트 스캐폴드 자동 생성
  • 누락된 케이스나 파라미터화 아이디어 제안받기 용이

https://docs.pytest.org/en/stable/

https://pypi.org/project/pytest/

1. 왜 테스트를 하는가?

소프트웨어 개발에서 테스트는 “코드가 약속한 조건을 지키는가?”를 자동으로 검증하는 과정입니다.

테스트를 잘 설계하면 리팩터링에 자신감을 얻고, 버그를 초기에 잡을 수 있으며, 협업 시 신뢰성이 올라갑니다.

테스트의 기본 철학은 AAA(Arrange–Act–Assert, 3A)입니다.:

1. Arrange: 준비 – 입력, 환경, 데이터 준비
2. Act: 실행 – 함수나 메서드 호출
3. Assert: 검증 – 기대한 출력과 비교

https://semaphore.io/blog/aaa-pattern-test-automation

1. pytest란 무엇인가?

pytest는 파이썬에서 가장 널리 쓰이는 테스트 프레임워크입니다.

https://youtu.be/cHYq1MRoyI0

주요 특징

• Autodiscovery: test_*.py 또는 *_test.py 형식의 파일, test_* 함수명을 자동으로 탐지
• Rich Assertion Introspection: assert 실패 시 실제 값과 기대 값을 직관적으로 출력
• Fixture 시스템: 테스트 준비/정리를 유연하게 관리
• 파라미터화 지원: 하나의 테스트를 여러 케이스로 반복 실행
• 호환성: unittest, nose 기반 테스트도 실행 가능
• 확장성: Django, Flask, Pandas 등 각종 플러그인 활용 가능

https://youtu.be/cHYq1MRoyI0

1. 개발환경과 실용 포인트

• IDE 통합: Pycharm, VSCode에서 테스트 함수 옆에 실행 버튼 표시 → CLI 없이도 클릭 실행
• 보고서 가독성: 실패 시 어느 값이 달랐는지 자세히 출력 → assertEqual 같은 메서드보다 직관적
• 마커(Markers): @pytest.mark.slow, skip, xfail로 실행/제외 제어 및 리포트에 태그 표시
• AI 보조: ChatGPT 등을 활용해 테스트 스캐폴드 자동 생성 → 누락된 케이스 점검에 유용

1. 핵심 테스트 유형과 예제

4.0 테스트 실행 및 해석 가이드

그래서 pytest는 어떻게 실행하는가!?

4.0.1 기본 실행 명령어

1
2
# 프로젝트 전체 테스트 실행
pytest

1
2
# 특정 파일의 테스트만 실행
pytest tests/test_unit.py

1
2
# 특정 함수만 실행
pytest tests/test_unit.py::test_normalize_whitespace

1
2
# 자세한 출력으로 실행 (각 테스트 이름과 결과 표시)
pytest -v

1
2
# 실패 시 즉시 중단
pytest -x

1
2
# print문 출력 보기 (디버깅용)
pytest -s

4.0.2 마커를 활용한 선택적 실행

1
2
# 느린 테스트 제외하고 빠른 테스트만
pytest -m "not slow"

1
2
# 통합 테스트만 실행
pytest -m integration

1
2
# 외부 의존성이 없는 테스트만
pytest -m "not external"

1
2
# 여러 조건 조합
pytest -m "not slow and not integration"

4.0.3 커버리지 측정

1
2
3
4
5
6
7
8
# 코드 커버리지와 함께 실행
pytest --cov=app

# HTML 리포트 생성
pytest --cov=app --cov-report=html

# 최소 커버리지 임계값 설정 (80% 미만시 실패)
pytest --cov=app --cov-fail-under=80

4.0.4 실행 결과 해석

✅ 성공적인 실행 예시:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ pytest tests/ -v

=================== test session starts ===================
platform darwin -- Python 3.11.0
cachedir: .pytest_cache
rootdir: /project
collected 8 items

tests/test_unit.py::test_normalize_whitespace PASSED    [12%]
tests/test_unit.py::test_clip[-0.1-0.0] PASSED         [25%]
tests/test_unit.py::test_clip[0-0] PASSED              [37%]
tests/test_unit.py::test_clip[0.5-0.5] PASSED          [50%]
tests/test_unit.py::test_clip[1-1] PASSED              [62%]
tests/test_unit.py::test_clip[1.1-1] PASSED            [75%]
tests/test_integration.py::test_db_flow PASSED         [87%]
tests/test_integration.py::test_api_flow PASSED        [100%]

=================== 8 passed in 1.23s ===================

🔍 해석:

• collected 8 items: 총 8개 테스트 발견
• PASSED: 각 테스트 성공
• [25%]: 전체 진행률
• 8 passed in 1.23s: 모든 테스트가 1.23초 만에 완료

❌ 실패가 있는 경우:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ pytest tests/test_unit.py::test_safe_div_raises -v

=================== FAILURES ===================
_______ test_safe_div_raises _______

    def test_safe_div_raises():
        with pytest.raises(ValueError, match="nonzero"):
>           safe_div(1, 0)
E           Failed: DID NOT RAISE ValueError

tests/test_unit.py:23: Failed
=================== short test summary info ===================
FAILED tests/test_unit.py::test_safe_div_raises - Failed: DID NOT RAISE ValueError
=================== 1 failed in 0.08s ===================

🔍 해석:

• FAILURES 섹션에서 실패 상세 정보 확인
• > 표시된 라인에서 실패 발생
• E 라인에서 실패 이유 설명
• 이 경우: ValueError가 발생할 것으로 예상했지만 발생하지 않음

4.0.5 개발 워크플로우 최적화

빠른 피드백을 위한 실행 전략:

1
2
3
4
5
6
7
8
9
# 개발 중: 빠른 유닛 테스트만
pytest -m "not slow and not integration" --ff

# 커밋 전: 변경된 파일 관련 테스트
pytest --lf  # 마지막 실패 테스트만
pytest --ff  # 실패했던 테스트 우선 실행

# CI/배포 전: 전체 테스트 + 커버리지
pytest --cov=app --cov-fail-under=80

디버깅을 위한 옵션:

1
2
3
4
5
6
7
8
9
10
11
# 첫 실패에서 중단하고 디버거 진입
pytest --pdb -x

# 더 자세한 출력
pytest -vv

# 경고 메시지 숨기기
pytest --disable-warnings

# 특정 로그 레벨 설정
pytest --log-cli-level=DEBUG

4.0.6 테스트 구성 파일 설정

pytest.ini 설정 예시:

1
2
3
4
5
6
7
8
9
[tool:pytest]
minversion = 6.0
addopts = -ra -q --strict-markers --strict-config
testpaths = tests
markers =
    slow: 실행 시간이 오래 걸리는 테스트
    integration: 여러 컴포넌트가 결합된 테스트
    external: 외부 서비스에 의존하는 테스트
    unit: 단일 함수/클래스만 테스트하는 유닛 테스트

실행 시나리오별 명령어 정리:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 🚀 개발 중 (빠른 피드백)
pytest -m "unit" -x

# 🔍 특정 기능 개발/디버깅
pytest tests/test_feature.py -v -s

# 📋 PR/커밋 전 점검
pytest -m "not external" --cov=app

# 🎯 CI/CD 전체 검증
pytest --cov=app --cov-report=xml --junitxml=test-results.xml

# 🐛 실패 원인 분석
pytest --lf --pdb -v

이제 테스트 실행의 기본기를 익혔으니, 구체적인 테스트 유형들을 살펴보겠습니다.

4.1 유닛 테스트 (Unit Test)

1
2
3
4
5
6
def normalize_whitespace(s: str) -> str:
    import re
    return re.sub(r"\s+", " ", s).strip()

def test_normalize_whitespace():
    assert normalize_whitespace("  Hello   World  ") == "Hello World"

• 무엇을 검증하나?

  • 공백 정규화 함수가
    • “여러 개의 공백/개행/탭 → 단일 공백”, “앞뒤 공백 제거”
  • 이라는 계약(contract)을 지키는지 확인합니다.

• 패스 조건

  • 입력 " Hello World "가 정확히 "Hello World"로 변환되면 통과합니다.

• 실패 예시

  • strip()을 누락하면 결과가 "Hello World"처럼 앞뒤 공백이 남아 실패합니다.
  • \s+ 대신 " "만 치환하면 탭/개행(\n, \t)이 한 칸으로 합쳐지지 않아 실패합니다.

• 왜 필요한가?

  • 전처리 파이프라인에서 문자열 규칙이 깨지면 후속 토큰화/정규식 매칭이 흔들립니다. 이 테스트는 순수 로직의 정확성을 고정합니다.

• 확장 아이디어

  • 파라미터화로 탭/개행/다국어 공백(예: \u00A0)도 케이스화하세요.

4.2 경계값 테스트 (Boundary)

1
2
3
4
5
6
7
8
import pytest

def clip(x, lo=0, hi=1):
    return max(lo, min(x, hi))

@pytest.mark.parametrize("x,expected", [(-0.1,0.0),(0,0),(0.5,0.5),(1,1),(1.1,1)])
def test_clip(x, expected):
    assert clip(x) == expected

• 무엇을 검증하나?
  • 값 x를 [lo, hi] 범위로 클리핑하는 함수가 경계 포함/초과 케이스에서 올바르게 동작하는지 확인합니다.
• 패스 조건
  • 하한 미만 → lo, 상한 초과 → hi, 범위 내 → x 그대로 반환해야 합니다.
• 실패 예시
  • min(x, hi) → min(hi, x)로 바뀌면 동작은 같지만, 범위 비교 로직을 잘못 바꾸다 >=/> 실수 시 특정 경계가 틀어져 실패합니다.
• 왜 필요한가?
  • 임계치 설정(확률, 점수, 정규화 값 등)에서 오버플로/언더플로 방지가 핵심입니다. 경계값은 버그가 가장 자주 숨어있는 지점입니다.
• 확장 아이디어
  • lo > hi인 잘못된 설정 입력 시 예외를 던지도록 스펙을 명확히 하고 예외 테스트를 추가하세요.

4.3 예외 처리

1
2
3
4
5
6
7
8
9
10
import pytest

def safe_div(a, b):
    if b == 0:
        raise ValueError("b must be nonzero")
    return a / b

def test_safe_div_raises():
    with pytest.raises(ValueError, match="nonzero"):
        safe_div(1, 0)

• 무엇을 검증하나?
  • 잘못된 입력(0으로 나눔)에서 명시적인 예외 타입·메시지를 발생시키는지 확인합니다. 실패도 스펙입니다.
• 패스 조건
  • safe_div(1, 0) 호출 시 ValueError가 발생하고 메시지에 "nonzero"가 포함되어야 합니다.
• 실패 예시
  • 예외를 던지지 않음 → ZeroDivisionError가 나중에 발생하거나 테스트가 계속 진행되어 실패.
  • 다른 타입의 예외를 던짐(ZeroDivisionError) → 타입 불일치로 실패.
  • 메시지가 바뀜 → match 정규식 미일치로 실패.
• 왜 필요한가?
  • 에러 핸들링 규약을 문서화/고정합니다. API 사용자(동료 코드)에게 예측 가능한 실패 시그널을 제공합니다.
• 확장 아이디어
  • 예외 경로 외에 정상 경로(b != 0) 테스트도 함께 두고, 양 경로 커버리지를 확보하세요.

4.4 픽스처 (Fixture)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
import pytest, csv

@pytest.fixture
def sample_csv(tmp_path):
    p = tmp_path / "data.csv"
    p.write_text("x,y\n1,2\n3,4\n", encoding="utf-8")
    return p

def sum_csv(path):
    with open(path) as f:
        return sum(int(r["y"]) for r in csv.DictReader(f))

def test_sum_csv(sample_csv):
    assert sum_csv(sample_csv) == 6

• 무엇을 검증하나?

  • 파일 I/O에 의존하는 함수가 주어진 CSV 스키마/내용에서 올바른 합계를 계산하는지 확인합니다.

• 패스 조건

  • 픽스처가 만든 임시 CSV에서 y 컬럼 합이 정확히 6이어야 합니다.

• 실패 예시

  • 인코딩/개행 처리 오류로 파싱 실패.
  • 헤더 오타("y"→"Y")로 KeyError 발생.
  • 정수 변환 실패(공백/NA)로 ValueError.

• 왜 필요한가?

  • 픽스처는 준비/정리 로직의 재사용과 독립 실행성을 보장합니다. tmp_path 덕분에 전역 파일 충돌 없이 테스트가 격리됩니다.

• 확장 아이디어

  • yield 픽스처로 리소스 해제(예: DB 커넥션) 포함.
  • 결측/잘못된 행이 있는 CSV를 추가 케이스로 만들어 강건성 테스트를 확장하세요.

• 그냥 함수와 무엇이 다른가?

  • 단순히 def sample_csv(): ...로 함수를 만들어 직접 호출할 수도 있지만, fixture는 pytest가 자동 호출과 주입을 해주기 때문에 테스트 본문이 “검증 로직”에만 집중할 수 있습니다.
  • 또한 scope, yield를 이용해 자원 수명 관리와 공유가 가능해 무거운 리소스(DB 연결, 파일 핸들 등)에도 적합합니다.

4.5 마커와 파라미터화

1
2
3
4
5
6
7
8
9
10
import pytest, time

@pytest.mark.slow
def test_slow_op():
    time.sleep(2)
    assert 1 + 1 == 2

@pytest.mark.parametrize("a,b,expected", [(1,2,3),(2,3,5)])
def test_add(a,b,expected):
    assert a + b == expected

• 무엇을 검증하나?

  • slow 마커: 느린 테스트를 식별/선택 실행할 수 있게 태깅합니다. 기능 자체 검증은 assert가 담당.
  • 파라미터화: 하나의 테스트 로직을 여러 입력/출력 케이스로 반복 실행해 커버리지를 올립니다.

• 패스 조건

  • test_slow_op: 잠깐 기다린 뒤 1+1==2가 참이면 통과. CI에서는 -m "not slow"로 제외해도 전체가 성공해야 합니다.
  • test_add: 각 튜플 (a,b,expected)마다 a+b==expected가 모두 참이면 통과.

• 실패 예시

  • 마커 미등록 상태에서 --strict-markers 사용 시 경고/에러.
  • 파라미터 목록과 인자 이름 개수 불일치 → 수집 에러.

• 왜 필요한가?

  • 실행 전략 관리(느린/외부의존/통합 구분)와 케이스 폭발 대응에 필수입니다.

• 확장 아이디어

  • ids=를 지정해 케이스 이름을 의미 있게 붙이면 실패 리포트 가독성이 좋아집니다.

4.6 모킹 (Mocking)

1
2
3
4
5
6
7
8
9
10
from unittest.mock import patch

@patch("requests.get")
def test_fetch_users(mock_get):
    mock_get.return_value.status_code = 200
    mock_get.return_value.json.return_value = [{"id":1,"name":"Alice"}]

    import requests
    resp = requests.get("http://fake")
    assert resp.json()[0]["name"] == "Alice"

• 무엇을 검증하나?

  • 외부 API 호출에 의존하는 코드가, 네트워크에 실제로 접속하지 않고도 예상된 응답 형태를 처리할 수 있는지 확인합니다.
  • 여기서는 requests.get을 패치해 가짜 응답 객체를 주입하고, .json() 반환값을 검증합니다.

• 패스 조건

  • requests.get이 호출되면, status_code==200이고 json()이 [{"id":1,"name":"Alice"}]를 반환해야 합니다.
  • 이후 응답 처리 로직이 "Alice"를 올바르게 읽으면 통과합니다.

• 실패 예시

  • 패치 대상 경로 오기 (@patch("my.module.requests.get") vs @patch("requests.get")) → 실제 네트워크 호출 시도/타임아웃.
  • 코드가 status_code를 검사하다 누락되어야 할 에러 경로가 통과하거나, 반대로 성공 경로에서 예외 발생.

• 왜 필요한가?

  • 외부 시스템(API/DB/파일시스템/시간)은 느리고 불안정합니다. 모킹으로 순수 로직만 격리해 빠르고 결정적인 테스트를 만듭니다.

• 확장 아이디어

  • 실패 경로 테스트: status_code=500 설정 후 with pytest.raises(...)로 예외를 요구하세요.
  • pytest-mock의 mocker 픽스처를 쓰면 assert_called_once_with 등 호출 검증이 간결합니다.

4.7 통합 테스트: In-Memory DB + 서비스 계층

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# app/db.py
import sqlite3

def init_db(path=":memory:"):
    conn = sqlite3.connect(path)
    conn.execute("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)")
    return conn

def add_user(conn, name):
    conn.execute("INSERT INTO users(name) VALUES (?)", (name,))
    conn.commit()

def list_users(conn):
    return [r[0] for r in conn.execute("SELECT name FROM users")]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# tests/test_integration_db.py
import pytest
from app import db

@pytest.fixture
def conn():
    conn = db.init_db()      # 격리된 in-memory DB
    yield conn
    conn.close()

def test_add_and_list_users(conn):
    # Arrange + Act (조합된 흐름)
    db.add_user(conn, "Alice")
    db.add_user(conn, "Bob")
    # Assert
    assert db.list_users(conn) == ["Alice", "Bob"]

• 무엇을 검증하나?

  • DB 초기화 → INSERT → SELECT까지 모듈 간 연결된 시나리오가 일관되게 동작하는지.

• 패스 조건

  • 추가한 순서대로 ["Alice", "Bob"]이 조회된다.

• 실패 예시

  • 테이블 스키마 불일치로 OperationalError
  • commit() 누락으로 빈 결과
  • 커넥션 공유/해제 실수로 ProgrammingError

• 왜 필요한가?

  • 단위 테스트는 함수 하나만 본다.
  • 통합 테스트는 상태 변화가 이어지는 흐름을 검증해 “붙였을 때 깨지는” 버그를 잡는다.

4.8 통합 테스트: FastAPI + DB 의존성 주입

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# app/api.py
from fastapi import FastAPI, Depends
import sqlite3

app = FastAPI()

def get_conn():
    # 실제 프로덕션에선 풀/파일DB 연결을 반환
    conn = sqlite3.connect(":memory:")
    conn.execute("CREATE TABLE IF NOT EXISTS items(id INTEGER PRIMARY KEY, name TEXT)")
    return conn

@app.post("/items")
def create_item(name: str, conn: sqlite3.Connection = Depends(get_conn)):
    conn.execute("INSERT INTO items(name) VALUES (?)", (name,))
    conn.commit()
    return {"ok": True}

@app.get("/items")
def list_items(conn: sqlite3.Connection = Depends(get_conn)):
    return [{"name": r[0]} for r in conn.execute("SELECT name FROM items")]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# tests/test_integration_api.py
from fastapi.testclient import TestClient
from app.api import app, get_conn
import sqlite3

def test_items_flow_using_overridden_dep():
    # 테스트용 단일 in-memory DB를 의존성으로 주입
    test_conn = sqlite3.connect(":memory:")
    test_conn.execute("CREATE TABLE items(id INTEGER PRIMARY KEY, name TEXT)")
    app.dependency_overrides[get_conn] = lambda: test_conn

    client = TestClient(app)

    # Act
    r1 = client.post("/items", params={"name": "apple"})
    r2 = client.post("/items", params={"name": "banana"})
    r3 = client.get("/items")

    # Assert
    assert r1.status_code == 200 and r2.status_code == 200
    assert r3.json() == [{"name": "apple"}, {"name": "banana"}]

    # 정리
    app.dependency_overrides.clear()
    test_conn.close()

• 무엇을 검증하나?

  • HTTP 계층(라우팅/직렬화) + DB 계층(삽입/조회)이 하나의 플로우로 결합되어 정상 동작하는지.
• • 패스 조건
  • POST 2회가 200을 반환하고, GET이 삽입된 아이템 목록을 그대로 반환한다.

• 실패 예시

  • 의존성 오버라이드 누락 → 각 요청마다 다른 새 DB로 연결되어 빈 결과
  • 트랜잭션/커밋 누락 → 조회 시 빈 목록
  • 라우팅 파라미터 이름/타입 불일치 → 422/500

• 왜 필요한가?

  • 실제 환경에 가까운 API‒DB 결합 동작을 빠르게 검증하면서도 네트워크/실DB 없이 격리 가능한 재현성을 확보한다.

4.9 통합 테스트: 파일 I/O + 파서 + 집계(ETL 미니 파이프라인)

1
2
3
4
5
6
7
8
9
10
# app/etl.py
import csv, json
from pathlib import Path

def run_etl(inp_csv: Path, out_json: Path):
    total = 0
    with inp_csv.open() as f:
        for row in csv.DictReader(f):
            total += int(row["value"])
    out_json.write_text(json.dumps({"total": total}, ensure_ascii=False), encoding="utf-8")

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# tests/test_integration_etl.py
from pathlib import Path
from app.etl import run_etl
import json

def test_etl_end_to_end(tmp_path):
    # Arrange: 입력 CSV와 출력 경로 준비
    inp = tmp_path / "in.csv"
    out = tmp_path / "out.json"
    inp.write_text("value\n1\n2\n3\n", encoding="utf-8")

    # Act
    run_etl(inp, out)

    # Assert: 산출물 존재 + 내용 검증
    assert out.exists()
    data = json.loads(out.read_text(encoding="utf-8"))
    assert data == {"total": 6}

• 무엇을 검증하나?
  • 파일 시스템 → CSV 파싱 → 집계 → JSON 산출까지 끝단 간 데이터 흐름이 깨끗하게 이어지는지.
• 패스 조건
  • 출력 파일이 생성되고 JSON 내용이 {"total": 6}.
• 실패 예시
  • 헤더 오타(value→values)로 KeyError
  • 비정상 값(공백/NA)로 ValueError
  • 경로/인코딩 문제로 파일 읽기/쓰기 실패
• 왜 필요한가?
  • 현실 업무의 많은 코드는 I/O + 변환 + 산출물로 이루어진다.
  • 통합 테스트가 산출물의 존재/형식/내용을 보증해 회귀를 막는다.

4.10 통합 테스트: 전처리 → 모델 학습/예측(ML 미니 파이프라인)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# app/mlpipe.py
import numpy as np
from sklearn.linear_model import LinearRegression

def preprocess(xs):
    # 음수 제거 + 정규화(간단 예시)
    arr = np.array([x for x in xs if x is not None and x >= 0], dtype=float)
    if arr.size == 0:
        return arr
    return (arr - arr.min()) / (arr.max() - arr.min() + 1e-12)

def fit_predict(xs, ys, xs_new):
    X = preprocess(xs).reshape(-1, 1)
    y = np.array(ys, dtype=float)
    model = LinearRegression().fit(X, y)
    preds = model.predict(preprocess(xs_new).reshape(-1, 1))
    return preds

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# tests/test_integration_mlpipe.py
import numpy as np
from app.mlpipe import fit_predict

def test_fit_predict_end_to_end():
    # Arrange
    xs = [0, 1, 2, 3, None, -1]   # None/-1는 전처리에서 제거
    ys = [0, 10, 20, 30]          # 선형 관계
    xs_new = [0, 1, 3]

    # Act
    preds = fit_predict(xs, ys, xs_new)

    # Assert: 출력 길이/범위/단조성 같은 "계약" 검증
    assert preds.shape == (3,)
    assert np.all(np.isfinite(preds))
    assert np.all(np.diff(preds) >= -1e-9)  # 단조 증가(수치 오차 허용)
    # 대략적 값 검증(완전 동일 아님)
    assert preds[0] < preds[1] < preds[2]

• 무엇을 검증하나?
  • 전처리 → 학습 → 예측까지 ML 파이프라인의 계약(invariants): 모양, 유한성, 단조성 등.

• 패스 조건

  • 예측 배열 길이가 입력 길이와 맞고, NaN/inf가 없으며, 단조 증가가 유지된다.
  • 데이터 노이즈·스케일링 차이에도 성질 기반(assertions on properties)이 통과한다.

• 실패 예시

  • 전처리에서 None/음수 필터링 미작동 → 학습/예측 실패 또는 NaN
  • 리샘플/리쉐이프 오류로 ValueError
  • 모델이 과적합/학습 실패로 단조성 붕괴

• 왜 필요한가?

  • 수치 테스트는 정답 숫자가 고정되기 어렵다.
  • 대신 형태·범위·성질을 통합 테스트로 고정하면 변경에 강하면서 회귀를 잡는다.

작은 운영 팁

• 통합 테스트는 느릴 수 있음 → 마커를 붙여 선택 실행: @pytest.mark.integration
• 공용 리소스(DB·브로커 등)는 픽스처 스코프(scope=”session”)로 비용 최소화
• “단위(많이) > 통합(적당히) > E2E(소수)” 테스트 피라미드 유지로 피드백 속도 확보

1. 고급 패턴

• Property-based Testing (hypothesis): 무작위 입력으로 항상 성질이 유지되는지 확인
• Regression Test: 과거 버그 케이스를 고정 테스트로 남겨 재발 방지
• Performance Test (pytest-benchmark): 특정 함수 성능 추적
• Async Test (pytest-asyncio): 비동기 함수 검증

1. AI를 활용한 테스트 자동화

강의의 독특한 포인트는 ChatGPT 활용입니다.

• 함수/클래스를 붙여넣고 → “pytest fixture/parameterize/raises를 활용해 테스트 코드 작성해줘” 요청
• AI가 골격을 자동 생성, 누락된 케이스까지 제안
• 개발자는 이를 검증·보완하는 방식으로 효율을 크게 높일 수 있음

1. 정리

pytest는

1. 직관적 문법 (assert) + 풍부한 리포트
2. Fixture/Marker/Parametrize로 강력한 확장성
3. IDE 통합, 호환성, AI 보조

이 세 가지가 합쳐지면서 “테스트가 귀찮은 부가 작업”이 아니라,
“코드 품질을 높이고 개발을 빠르게 하는 도구”임을 체감하게 됩니다.

• Previous
  [접속] 원격 개발에서 비밀번호 없이 접속하기 (SSH/VSCODE 원격 접속)
• Next
  [Paper Review] EXAONE 4.0: Unified Large Language Models Integrating Non-reasoning and Reasoning Modes