페이지 오브젝트 모델(POM)은 UI 테스트에서 자동화 테스트 코드를 구성하기 위한 아키텍처 패턴입니다. 이는 애플리케이션의 각 페이지에 대한 논리적 표현을 위해 개별 클래스 또는 객체를 정의하고, 요소와 그에 대한 작업을 처리하는 메소드를 정의하는 것을 제안합니다.
문제 배경: 이전에 자동화 테스트는 "있는 그대로" 작성되었으며, 테스트 내에서 요소의 로케이터와 직접 상호작용하여 코드 중복과 유지보수의 복잡성을 초래했습니다. POM이 도입되면서 특정 페이지와 관련된 모든 내용을 개별 클래스에 분리하여 자동화 테스트를 더 쉽게 관리할 수 있게 되었습니다.
문제: 대규모 프로젝트에서 테스트를 구조화하지 않으면 "혼란스러운" 코드가 신속하게 쌓입니다. 인터페이스에서의 모든 변경은 수많은 테스트를 업데이트해야 하며, 이는 유지보수 비용이 높아지는 결과를 초래합니다.
해결책: POM은 작업 및 요소를 중앙집중적으로 관리할 수 있게 해주며, 코드 중복을 감소시키고 테스트 인프라 구조의 확장을 용이하게 합니다. 예를 들어, 버튼의 로케이터를 변경해야 할 경우 수정은 단 하나의 장소인 페이지 오브젝트에서만 이루어지며, 모든 테스트에서 변경할 필요가 없습니다.
주요 특징:
POM 패턴 없이 자동화 테스트를 구현할 수 있나요?
가능하지만, 이런 접근 방식은 코드 중복, 높은 유지보수 비용 및 확장 불가능성을 초래합니다.
각 페이지의 모든 요소를 개별 페이지 오브젝트로 만들어야 하나요?
아니요, 페이지 오브젝트는 연결된 요소와 작업을 포함하는 논리적인 페이지를 위해 생성되며, 가끔씩 작은 반복 블록은 개별 보조 개체(예: 컴포넌트)를 사용할 수 있습니다.
POM이 자동화 테스트의 모든 아키텍처 문제를 해결하나요?
아니요, POM은 인터페이스 작업의 논리를 구조화하는 데 도움을 주지만, 테스트 프레임워크의 전체 아키텍처를 정의하지 않습니다. 예를 들어, 데이터 처리, 보고서 생성 및 애플리케이션 상태 관리 등입니다.
자동화 테스트가 POM 없이 작성되었습니다. 모든 작업이 테스트 메소드 내에 직접 작성되었습니다. 결과적으로 한 페이지에서 버튼의 id를 간단히 변경하는 것만으로도 35개의 테스트를 수정해야 했고, 많은 테스트가 부정확해지거나 아예 실행되지 않게 되었습니다.
장점:
단점:
새로운 프로젝트에서 테스트는 POM을 기반으로 구축되었습니다. 페이지 클래스를 추가하고, 요소 작업을 캡슐화하며, 공통 패턴을 위해 상속을 사용했습니다.
장점:
단점: