GitLab QA의 페이지 오브젝트

GitLab QA에서 사용하는 Page Object 패턴의 개념, 구현 방법, 엘리먼트 정의 및 선택자 활용 방법을 설명합니다.

GitLab QA에서는 Page Objects 라고 불리는 잘 알려진 패턴을 사용합니다. 이는 GitLab QA 시나리오를 실행하기 위해 사용하는 GitLab의 모든 페이지에 대한 추상화를 구축했음을 의미합니다. 폼 작성이나 버튼 선택처럼 페이지에서 무언가를 수행할 때마다, GitLab의 해당 영역과 연결된 페이지 오브젝트를 통해서만 작업을 수행합니다. 예를 들어, GitLab QA 테스트 하네스가 GitLab에 로그인할 때 사용자 로그인 정보와 비밀번호를 입력해야 합니다. 이를 위해 Page::Main::Login 클래스와 sign_in_using_credentials 메서드를 사용하며, 이 코드만이 user-login 및 user-password 필드를 읽는 유일한 코드입니다. 왜 필요한가? # 페이지 오브젝트가 필요한 이유는 코드 중복을 줄이고, 누군가 GitLab 소스 코드의 선택자를 변경했을 때 발생하는 문제를 방지하기 위해서입니다. GitLab QA에 수백 개의 스펙이 있고, 매번 어서션을 수행하기 전에 GitLab에 로그인해야 한다고 가정해 보세요. 페이지 오브젝트 없이는 불안정한 헬퍼에 의존하거나 Capybara 메서드를 직접 호출해야 합니다. 모든 *_spec.rb 파일/테스트 예제에서 fill_in 'user-login' 을 직접 호출하는 상황을 상상해 보세요. 나중에 누군가 이 페이지와 연결된 뷰에서 t.text_field 'login' 을 t.text_field 'username' 으로 변경하면 다른 필드 식별자가 생성되어 모든 테스트가 실질적으로 중단됩니다. Page::Main::Login.perform(&:sign_in_using_credentials) 를 GitLab 로그인이 필요한 모든 곳에서 사용하기 때문에, 페이지 오브젝트가 단일 진실 공급원(Single Source Of Truth, SSOT)이 되어 fill_in 'user-login' 을 fill_in 'user-username' 으로 한 곳에서만 수정하면 됩니다. 과거에 어떤 문제가 있었나? # 성능상의 이유와 패키지 빌드 및 전체 테스트에 소요되는 시간 때문에 모든 커밋에 대해 QA 테스트를 실행하지는 않습니다. 그렇기 때문에 누군가 new session 뷰에서 t.text_field 'login' 을 t.text_field 'username' 으로 변경하더라도, GitLab QA 야간 파이프라인이 실패하거나 누군가 머지 리퀘스트에서 package-and-qa 액션을 트리거하기 전까지는 이 변경 사항을 알 수 없습니다. 이러한 변경은 모든 테스트를 중단시킵니다. 이 문제를 *취약한 테스트 문제(fragile tests problem)*라고 부릅니다. GitLab QA를 더 신뢰할 수 있고 견고하게 만들기 위해, GitLab CE/EE 뷰와 GitLab QA 사이에 결합(coupling)을 도입하여 이 문제를 해결해야 했습니다. 취약한 테스트 문제를 어떻게 해결했나? # 현재, 새로운 Page::Base 파생 클래스를 추가할 때 페이지 오브