[자동화] Screenplay 패턴을 알아보자!

0. 개요

자동화를 구축할 때, POM을 배우고 구축을 했었다.

오직 POM만 알고 있었고, POM이 가장 좋은 디자인 패턴일 것이라 생각했다.

배울 때 두나무, 올리브영 같은 큰 기업의 QA 블로그에서 참고했었기 때문에, 타당한 선택이었을 것이라 생각했기 때문이기도 하다!

https://velog.io/@tkjung/Appium-POM%EC%9D%84-%EC%A0%81%EC%9A%A9%ED%95%9C-%EC%9E%90%EB%8F%99%ED%99%94-%EA%B5%AC%EC%A1%B0-%EC%84%A4%EA%B3%84

두나무 QA - POM 적용 가이드

https://oliveyoung.tech/2023-11-11/qa/

올리브영 QA - POM 적용 가이드

 

사실 스포하자면, POM이 잘못된 것은 아니다. POM과, Screenplay 둘 다 장단점이 뚜렷하게 존재한다. 

---

1. POM

POM은, Page Object Model의 약자다.

이 디자인 패턴의 가장 중요한 두가지 포인트는, 페이지 오브젝트와 테스트로 구분된 패턴이다.

페이지 오브젝트는, 페이지의 요소와 행동을 저장한다.

테스트는, 페이지 오브젝트에서 만들어낸 행동을 조립해서 테스트 케이스를 구현한다.

├── TestCases
│   ├──__init__.py
│   │── conftest.py
│   └── test_homePage.py
├── page_objects
│   ├── __init__.py
│   ├── signupPage.py
│   └── homePage.py
└── Utilities
│   └── __init__.py
└── config.py

위처럼, page_objects 폴더와 testcases 폴더를 나눈 예시를 볼 수 있다. (출처 : 올리브영 QA 블로그)

1-1. 페이지 오브젝트

class homePage(BasePage):
    #요소
    SIGN_UP_LINK = (By.CSS_SELECTOR, 'a[href="/register"]')
    POST_BTN = (By.CSS_SELECTOR, 'button[type="post"]')
    ARTICLE = (By.CSS_SELECTOR, 'article')
    
    def __init__(self, driver):
        super().__init__(driver)
    #행동
    def click_sign_up_link(self):
    	self.click_element(self.SIGN_UP_LINK)
        
    def click_new_post_btn(self):
        self.click_element(self.POST_BTN)
        
    def is_article_visible(self):
        return self.is_element_appear(self.ARTICLE)

페이지 오브젝트의 샘플 코드다.

작성 방법으로는 아래와 같다.

1. 페이지에 있는 요소를 식별할 로케이터를 적는다.
2. 이 페이지에서 일어날 행동들을 요소를 활용해 적는다.

1-2. 테스트

'''
tests/test_home.py
'''
try:
    #사전 조건
    homePage.click_sign_up_link()
    signupPage.sign_up.sign_up()
    
    #테스트 진행
    homePage.click_new_post_btn()
    homePage.post_article()
    
    #검증
    assert homePage.is_article_visible() == True

이런식으로, 테스트 스크립트가 작성된다.

즉, 페이지 오브젝트에서 작성된 행동을 가져와서, 테스트가 구성된다.

---

2. POM의 장/단점

그렇다면, POM의 장단점은 무엇일까?

2-1. 장점

1. 러닝커브가 낮다.
   가장 많이 쓰이기도 해서 예시를 찾아보기가 정말 쉽기도 하다. 이것만 알았을땐 몰랐는데, 정말 간단한 패턴이라고 느꼈다.
2. 직관적이다.
   어떤 행동을 했는지 알기 쉽다. 그래서,  TC와 1대1 매칭되는 스크립트 작성을 할 수 있다.

2-2. 단점

1. 재사용성에 한계가 있다.
   동일 페이지 내의 요소나 행동은 재사용하기는 정말 좋다.
   하지만 만약 서로 다른 페이지에서, 중복되는 행동이 있다면?
   ex) 로그인 페이지, 회원가입 페이지에는 계정 입력, 비밀번호 입력과 같은 중복 코드가 발생할 수 있다.
2. 페이지가 너무 복잡하면, 페이지 오브젝트는 더더욱 복잡해진다.페이지가 정말 단순하다면 괜찮지만, 하나의 페이지에서 수많은 오브젝트가 있다면 요소를 따는데에만 수십, 수백줄이 발생한다.
   또, 그에 맞는 행동 또한 계속 작성해야 한다. 수많은 요소들의 행동까지 적는다면 페이지 오브젝트는 꽉차고 말 것!

---

3. Screenplay 패턴

앞서, 한국어로 된 Screenplay 설명 자료가 없었다.
영어 번역본이나, LLM의 도움으로 작성했고, 일부는 직접 각색해 작성한 내용이다.
틀린 내용이 있을거고, 추상적으로만 작성했다.

 

Screenplay 패턴은, Actors, Abilities, Interactions,tasks, Questions 로 나뉜다.

• Actor : 누구
• Ability : 드라이버, API 호출등의 능력
• Interactions : 작은 행동
• Tasks : Interaction들을 조립해 만든 복잡한 행동
• Questions : 검증을 위한 질문

3-1. Actors

능력이 적용된 누구를 담당한다.

테스트 수행을 하고, 검증을 한다.

많은 샘플에서는 실제 이름을 사용하는데, 현업이라면 Admin, Biz, normal과 같이 역할군에 따라 나누는 것이 좋아 보인다!

3-2. Abilities

능력을 담당한다.

browseTheWeb, callAPI와 같은 능력이 있다.

Actor에게 능력을 부여한다.

3-3. Interactions

클릭, 텍스트입력, url 실행, 드롭다운 목록 선택과 같은 interaction 이 있다.

최소한의 행동을 작성한다.

3-4. tasks

interaction의 행동들이 모여 로그인과 같은 task를 구성한다.

(아이디,비밀번호 입력 + 로그인 클릭) = 로그인 task

3-5. Questions

검증을 위한 질문이 포함된다.

만약 browsetheweb 능력이 있다면, 웹에서 로고가 있는지, 입력란들이 있는지를 질문을 던진다.

만약 CallAPI 능력이 있다면, 버튼을 눌렀을때 2xx 응답이 왔는지 질문을 던진다.

그 질문에 대해, actor가 응답하는 식이다.

즉, A actor에게는 보이고 B actor에게는 안보이는 요소가 있다면, A에는 True, B에는 False와 같은 응답값을 기대할 수 있다.

3-6. 요약하자면!

즉, 어떤 능력(Ability)을 가진 누가(Actors) 어떤 행동을 하고(Interactions,Tasks) 검증을 한다(Questions)는 걸 몽땅 나눈 패턴으로 보인다.

실제 Screenplay 패턴을 구조화 한다면 아래와 같다.

출처 : https://serenity-js.org/handbook/design/screenplay-pattern/

 

---

4. Screenplay 패턴 장단점

그렇다면 Screenplay의 장단점은 뭐가 있을까?

4-1. 장점

1. 재사용성이 뛰어나다.
   그도 그럴 것이, 몽땅 다 분리해놨다. 기존 POM의 단점을 극복한 격.
   따라서 구축 이후에는 유지보수도 더욱 쉽다. 
2. 복잡한 시나리오에 강하다.
   역할군, 행동, 검증 등 모두 분리된 만큼, 복잡한 시나리오에 대처가 쉽다.
   POM에 비교하자면, "어떤 페이지에서 어떤걸 누르고 어떤 페이지에선 어떤걸 누르고..." 와 같은 시나리오가 아니라, 정말 테스터를 하나 가져다놓고 행동 중심으로 작성할 수 있다. 

4-2. 단점

1. 아찔한 러닝커브
   한국어로 된 내용도 없고, 그나마 된 영어 내용들도 뭔가 부족하다.
   일부 사이트들은 404로 이미 삭제가 되어있기도 하고..
   그 뿐 아니라, 팀 모두에게 이해시키기는 POM이 조금 더 나은 편일 것 같다.
   신입 입장에서 저런 식으로 쪼개져있으면 설명만 한세월 걸릴듯
2. 오버엔지니어링
   만약 정말 단순한 웹페이지를 담당할 것이라면 POM이 좋은 선택지일 듯 하다.
   필수 폴더만 5개가 넘어가는데, 서로를 연결해주고 사용성 높이는데에는 엄청난 수고가 예상된다.

---

5. 총평 및 정리

POM과 Screenplay의 총 평가는 이렇다.

항목	POM	Screenplay
재사용성	제한	높음
초기 구축	쉬움	어려움
추천 서비스	단순한 서비스	복잡한 서비스
추천 조직	자동화 초기	자동화 성숙

사실 작성하면서 느낀게, 

POM을 먼저 도입하고, 불편함을 느끼면 Screenplay와 같은 개선을 이루는게 맞다고 생각한다.

(몇 안되는..) Screenplay 정리글을 보면, POM은 잘못된게 아니라 다만 개선이 필요한 것이라고 한다.

그 개선을 이룬게 Screenplay라고 생각된다.

다만! 그렇다고 이런 디자인 패턴을 알게 된건, 우물안의 개구리임을 느끼게 해주는 내용이었다.

그리고, 실무에서 자동화 구축에 대한 자신감 또한 얻을 수 있었다.

POM이 맞을까? 라는 의문을 가진 상태였는데, 다양한 디자인 패턴이 있으나 POM이 전통적으로 많이 쓰인다는 사실을 알게 되었던 것!

아직 샘플코드는 보진 않았고, 개념만을 겉핥기로 읽었지만, 만약 자동화 구축 단계에 있다면 한번 읽어보고 자동화 구축의 선택지를 높여볼 수 있을 것 같다!