[SWE-003][입문] 단위·통합·E2E 테스트의 범위 구분하기 > IT 기술 공유

• 목록

[이번 수업]
같은 주문 기능을 단위, 통합, E2E 관점에서 검사합니다. 단위는 작은 로직, 통합은 구성요소의 연결, E2E(End-to-End)는 사용자 시작점부터 최종 결과까지의 흐름을 확인합니다. Python 표준 `unittest`만 사용합니다.

[선수지식]
SWE-001의 기능 분해와 SWE-002의 함수·모듈 개념을 알면 좋습니다.

[학습목표]
1. 단위·통합·E2E 테스트의 경계를 설명합니다.
2. 준비, 실행, 검증 순서로 테스트를 작성합니다.
3. 빠른 테스트와 실제 흐름 테스트를 함께 배치합니다.

[핵심개념]
단위 테스트는 함수나 클래스처럼 작은 대상 하나를 격리해 검사합니다. 빠르고 실패 원인을 찾기 쉬워 입력 경계와 오류 조건을 많이 확인하기 좋습니다. 통합 테스트는 주문 로직과 재고 저장처럼 둘 이상의 구성요소가 약속대로 연결되는지 봅니다. 데이터 형식과 상태 변경 문제를 찾는 데 유용합니다.

E2E 테스트는 브라우저·API 같은 공개 진입점에서 시작해 서버와 저장소를 거쳐 사용자가 보는 결과까지 확인합니다. 실제 사용에 가깝지만 준비가 크고 느릴 수 있습니다. 단위 테스트를 넓게 두고 중요한 연결과 핵심 사용자 여정을 통합·E2E로 보완하세요. 아래 E2E는 한 파일 안의 축소 모형이며 실제 웹 E2E에는 별도 실행 환경과 브라우저가 필요합니다.

[따라하기]
아래 내용을 `test_order.py`로 저장하세요. 계산 함수, 재고 연결, 구매 후 품절되는 흐름을 차례로 검사합니다.

```python
import unittest

def subtotal(prices):
    if any(price < 0 for price in prices):
        raise ValueError("price must be non-negative")
    return sum(prices)

def order(item, quantity, price, stock):
    if quantity < 1:
        return {"status": 400}
    if stock.get(item, 0) < quantity:
        return {"status": 409}
    stock[item] -= quantity
    return {"status": 201, "total": subtotal([price] * quantity)}

class OrderTests(unittest.TestCase):
    def test_unit_subtotal(self):
        self.assertEqual(subtotal([1000, 2000]), 3000)

    def test_integration_order_and_stock(self):
        stock = {"book": 2}
        self.assertEqual(order("book", 1, 1500, stock)["status"], 201)
        self.assertEqual(stock["book"], 1)

    def test_e2e_user_journey(self):
        stock = {"book": 1}
        self.assertEqual(order("book", 1, 1500, stock)["status"], 201)
        self.assertEqual(order("book", 1, 1500, stock)["status"], 409)

if __name__ == "__main__":
    unittest.main()
```

macOS/Linux와 Windows PowerShell은 `python test_order.py -v`로 실행합니다. Python 명령이 `python3`이면 `python3 test_order.py -v`를 사용하세요. 예상 결과는 세 테스트 이름 뒤에 `ok`, 마지막에 `Ran 3 tests`와 `OK`입니다.

[흔한 실수]
내부 구현 순서까지 고정하면 리팩터링만 해도 테스트가 깨집니다. 공유 상태나 실행 순서에 의존하지 마세요. 성공 경우만 보지 말고 수량 0, 재고 부족, 음수 가격 같은 경계도 넣습니다. E2E를 너무 많이 만들면 느리고 불안정해질 수 있습니다. 브라우저에서는 고정 시간보다 화면 상태를 기다리는 검증을 사용합니다.

[보안 주의]
본인 소유의 로컬·격리 환경과 가짜 데이터에서 실행하세요. 운영 결제·메일·삭제 API를 호출하지 말고 테스트용 구현과 별도 자격증명을 사용합니다. 비밀번호·토큰·개인정보를 코드나 실패 로그에 넣지 않습니다. 인증 실패, 다른 사용자 리소스 거부, 잘못된 입력 거부 같은 방어 동작도 확인합니다.

[직접 해볼 과제]
수량 0이면 상태 400인지 검사하는 테스트와, 음수 가격이면 `ValueError`가 발생하는 테스트를 추가하세요. 결과가 `Ran 5 tests`와 `OK`인지 확인합니다.

[확인문제]
1. 계산 함수 하나를 빠르게 검사하기에 알맞은 테스트는 무엇인가요?
2. 통합 테스트가 단위 테스트보다 잘 찾는 문제는 무엇인가요?
3. 모든 경우를 E2E로만 만들면 어떤 문제가 생길 수 있나요?

[다음 학습]
전체 순환의 다음 수업은 MOBILE-003 ‘화면·컴포넌트·내비게이션’입니다. 이어서 SWE-004 ‘TDD와 테스트 더블’을 배웁니다.

[공식 참고 자료]
Python unittest: https://docs.python.org/3/library/unittest.html
Python 테스트 코드 구성: https://docs.python.org/3/library/unittest.html#organizing-test-code
Playwright 웹 검증: https://playwright.dev/docs/test-assertions
W3C WebDriver 표준: https://www.w3.org/TR/webdriver2/
OWASP 웹 보안 테스트 가이드: https://owasp.org/www-project-web-security-testing-guide/