UI 자동화 (웹·모바일)

UI 자동화란 무엇인가: 언제, 왜 필요한가

피라미드 꼭대기에 있는 UI 자동화는 가장 비싸고 불안정하다. 그래서 무엇을 UI 자동화로 남겨야 하는지 신중하게 판단해야 한다.

Playwright로 첫 자동화 테스트 작성하기

브라우저를 자동으로 조작하는 Playwright의 기본 구조를 익힌다. 요소를 찾고, 행동을 흉내 내고, 결과를 검증하는 흐름은 모듈 10에서 배운 AAA 패턴 그대로다.

깨지지 않는 로케이터 설계하기: 사용자 관점으로 요소 찾기

디자인이 바뀔 때마다 테스트가 깨진다면 로케이터 설계가 잘못된 것이다. CSS 클래스가 아니라 사용자가 인식하는 방식으로 요소를 찾는 원칙을 익힌다.

Page Object Model: 유지보수 가능한 테스트 구조 만들기

로케이터가 테스트 코드 곳곳에 흩어져 있으면 화면 하나가 바뀔 때마다 수십 곳을 고쳐야 한다. 화면을 하나의 객체로 감싸는 POM 패턴으로 이 문제를 해결한다.

대기 전략: sleep() 대신 무엇을 써야 하는가

"3초만 기다려라"는 식의 고정 대기는 UI 자동화에서 가장 흔한 실수다. 조건이 충족될 때까지 기다리는 올바른 대기 전략을 익힌다.

UI 자동화에서 불안정한 테스트 다루기

UI 자동화는 태생적으로 플래키해지기 쉽다. 로케이터·대기·환경·테스트 데이터, 네 가지 관점에서 원인을 진단하고 대응하는 체계적인 접근을 익힌다.

모바일 자동화 기초: Appium과 웹 자동화의 차이

앱은 브라우저가 아니다. 네이티브 앱, 하이브리드 앱의 차이를 이해하고, Appium이 웹 자동화와 어떤 개념을 공유하고 어떤 점이 다른지 익힌다.

크로스 브라우저·디바이스 자동화 전략

모든 브라우저와 모든 기기에서 전체 테스트를 다 돌리는 건 비현실적이다. 무엇을 어디까지 커버할지 우선순위를 정하는 전략으로 이 모듈을 마무리한다.

Cypress — Playwright·Selenium과 무엇이, 왜 다른가

웹 UI 자동화 3대 도구 중 하나인 Cypress를 Playwright와 비교한다. 같은 목표(브라우저를 코드로 조작)를 다른 구조로 풀어낸 선택이 실무에 어떤 차이를 만드는지 이해한다.

테스트 데이터 부재 해결 — API Fixture 자동화 설계와 실패 단계별 자동 트리아지

E2E 테스트가 "시험할 주문이 없어서", "쿠폰이 이미 쓰여서" 실패한다면 그것은 테스트 데이터 부재 문제다. 사전 조건을 추출해 API로 상태를 만들고 테스트에 주입한 뒤 실행하고 정리하는 다섯 단계 파이프라인, Playwright test.extend 기반 Custom Fixture 구현, UI로 데이터를 만들지 않는 원칙과 fixture_payload 메타데이터·멱등성 접두사·API 토큰 사전 주입, 그리고 Fixture 단계 실패는 환경 문제로, UI 단계 실패는 셀렉터 오류나 실제 버그로 자동 분류하는 트리아지 로직을 다룬다.