Airflow에 새로운 e2e Test 구조 도입 및 표준화

정보공유
1

최근 Airflow dev 메일링 리스트에서 꽤 뜨거운? 제안이 나왔습니다.
바로 새로운 e2e(end-to-end) 테스트 구조를 도입하고 이를 표준화하자는 제안입니다.

Airflow 내부 테스트 구조가 복잡하다는 것은 저희 커뮤니티 기여 모임을 진행하면서 부터 있었는데, 이번 논의는 그 문제를 본격적으로 해결할 중요한 전환점이 될 것 같습니다.

https://lists.apache.org/thread/62wfkcoj2xgxv092dgynl5ltfpv1v8yb

제안 배경

Airflow 저장소에는 현재 여러 종류의 e2e 목적 테스트 디렉토리가 존재하나, 이름, 구조, 방법이 제각각이라 일관성 부족과 유지보수 어려움이 있는 상황입니다.

예를 들면:

  • docker-tests
  • k8s-tests
  • airflow-e2e-tests
  • airflow-ctl-tests
  • task-sdk-integration-tests
  • …etc

각자 독립적으로 만들어지다 보니, 테스트를 찾기 어렵고, 유지보수 난이도도 높아지고, 재사용성도 떨어지는 문제가 생겼습니다.

그런 와중에 최근 등장한 task-sdk-integration-tests의 구조가 좋다고 평가되었고, 이를 Airflow 전체 테스트의 표준 모델로 삼아보자는 의견이 모이고 있습니다.

표준 e2e 테스트 구조 특징

task-sdk의 구조는 아래와 같은 장점 덕분에 테스트 표준 구조 후보가 되었습니다:

  • uv + pytest 기반으로 표준화
  • docker-compose + python-on-whales로 Airflow 컴포넌트 자동 실행
  • pytest 테스트는 uv sync가 관리하는 venv에서 실행
  • 핫 리로드 지원
    • 변경한 Airflow 코드를 저장하면 도커 컨테이너 안에서 즉시 반영
    • 테스트 재실행 시 즉시 새로운 코드가 반영됨 (sub-second)
  • CI 자동 실행, 로컬에서도 쉽게 uv run pytest로 실행 가능
  • 각 Airflow distribution는 자신만의 e2e 테스트 세트를 가질 수 있음
    • 즉 provider, chart, task SDK 등이 각각 필요한 e2e 테스트를 가질 수 있게 됨

제안된 구조 개편

그래서 어떻게 변경이 될 것인가? 해서 보면, 제가 이해하기론 아래와 같이 될 것 같습니다.

기존 구조

task-sdk
├─ src
├─ tests
│   └─ task_sdk
└─ task-sdk-integration-tests
    ├─ dags
    ├─ logs
    └─ tests

제안된 구조

모든 e2e 테스트를 tests/e2e 아래로 통합

task-sdk
├─ src
└─ tests
    ├─ unit
    │   └─ task_sdk
    └─ e2e
        ├─ dags
        ├─ logs
        └─ task_sdk

또한, 공통 기능은 devel-common으로 추출하여 재사용.

한 가지 문제? 그럼… k8s test는 어디 둘 것인가?

이 부분이 제안 중 논의가 있었던 부분입니다. 의견을 요약하면 다음과 같습니다.

chart에 둬야 한다

  • 대부분 Helm chart 기반으로 Airflow 설치를 검증하므로 chart가 자연스럽다.

airflow-core 쪽이 더 맞다

  • chart 테스트라기보단 Airflow 전반(K8s provider, Task SDK 포함)을 테스트하는 경우가 많다.

기능별로 분리하자

  • KE / KPO → cncf.kubernetes provider
  • Helm 기반 Airflow 전반 테스트 → chart 또는 helm_tests

결론은?

일단 이 문제는 별도 논의로 분리하고, 지금은 전체 e2e 표준화 작업부터 진행하자!!
즉, lazy consensus 진행 중이며 특별한 반대가 없으면 표준 구조화가 진행될 예정입니다.

마무리하며

Airflow에 기여하다보면 test 구조가 조금 복잡하긴 했습니다.
이 테스트 구조를 일관성있게 재편성하는 것은 더 접근성 높은 Airflow 개발 경험을 만들어 줄 것으로 보입니다.

물론…
작업량 자체는 적지 않을 것 같지만요 :smiling_face_with_tear:
그래도 장기적으로는 큰 도움이 될 변화라고 생각합니다.