페이지 개체 모델의 문제점

테스트 자동화 디자인 패턴

SDET 그리고 테스트 아키텍트를 목표로 커리어를 성장하는 요즘, 테스트 자동화 분야에서 일반적으로 많이 활용되는 페이지 개체 모델에 대해 조금 더 깊게 생각해보게 되었다. 

페이지 개체 모델의 핵심 설계 패턴은 모든 테스트 개체를 저장하는 개체 저장소를 만들어 관리하는 것이다. 일반적으로 각 개체 저장소에는 각 페이지에 해당하는 동작 메서드가 구현된다. 각 페이지 클래스는 전체 페이지에서 공통적으로 사용할 동작 메서드가 구현되어 있는 BasePage를 상속받는다. 코드 중복을 줄이고 개체 유지 관리를 단순화시키는 것이 페이지 개체 모델의 핵심이자 목적이다. 유용하고 큰 문제가 없어 보이지만 조금 더 생각해보면 페이지 개체 모델은 소프트웨어 테스트 관점에서 여러 문제가 발생한다.

페이지 개체 모델은 초기 설계 단계에서 서비스의 동작 측면 보단 각 페이지 측면에서 설계가 이루어진다. 로그인, 회원가입, 홈.. 과 같이 서비스의 여러 기능을 페이지로 나누는 행위를 뜻한다. 즉 실제 사용자의 동작 관점에서 설계가 진행되기보단 페이지 개체 모델 접근에 의한 페이지 측면에서의 설계가 진행된다. 이러한 설계 접근 방식은 인수 테스트에서 중요한 테스트 관점에서 벗어나게 된다. 인수 테스트의 핵심은 비즈니스 로직의 실제 사용자 동작 검증이 되어야 한다. 하지만 설계 관점에서부터 페이지 단위로의 구현이 진행되다 보니 전체적인 테스트 설계가 사용자의 동작 중심에서의 접근 보단, 개체 모델 접근을 하기 위한 설계가 이뤄진다. 간단한 서비스 및 테스트 자동화 커버리지를 높게 가져가는 조직이 아니라면 문제가 될 사항은 크게 없지만 소프트웨어 테스트 그리고 블랙박스 테스트의 인수 테스트 레벨의 관점에서 해석한다면 분명 좋지 못한 설계로 이루어진 코드를 계속해서 구현하는 상황이 발생한다.

뿐만 아니라 페이지 개체 모델로 접근하다 보면 객체 지향의 단일 책임 원칙을 자연스레 위반하게 된다. 클래스가 하나의 기능만을 처리하는 것이 아닌 페이지 단위로 필요한 메서드를 구현하다 보니 특정 페이지에서 상호작용되는 모든 메서드를 구현하게 된다. 연관성 높은 메서드가 구현되는 페이지라면 크게 문제가 없지만 그렇지 않을 경우 장기적인 관점에서 유지 관리가 어려워지는 문제점이 발생한다.

물론 이러한 페이지 개체 모델의 문제점이 존재하기에 기본적인 페이지 개체 모델 디자인의 이점을 가져가되 변형된 접근 방식을 통해 문제점을 해결하려는 방법도 있지만, 결국 페이지 개체 모델의 핵심적인 설계의 틀은 벗어나지 않기 때문에 상충 관계(trade-off)가 발생한다.

이러한 문제를 소프트웨어 설계 관점에서 해결하고 서비스 구현 사항 분석을 토대로 사용자 중심 접근 방식인 시나리오 패턴과 같은 방식으로 기술적인 의견과 해답을 적절한 시기에 제시하고 구현 가능한 QA Engineer가 되어야겠다.