[Appium, iOS 기준] Appium, Appium Inspector, WDA란? 왜 설치할 게 이렇게 많은가?

Appium을 설치하고 실행하기 위해 많은 레퍼런스를 찾아봤지만, 설치하라는 것도 많고 이름도 비슷한 데다 헷갈리는 부분들이 많았다.

스스로 개념을 정리하기 위함과 Appium을 이용해 테스트 자동화를 시도하는 사람들의 개념 정리에 조금이나마 도움이 되길 바라는 마음으로 작성했다.

🎀 Appium

오픈 소스 모바일 자동화 테스트 프레임워크로, iOS와 Android를 모두 지원하며 다양한 앱을 테스트 할 수 있다.

 

Appium은, Node.js를 사용해 작성된 HTTP 서버 이다.

그래서 Appium을 설치하기 전에, Node.js를 반드시 설치해야 한다. 하지만 대부분은 이미 설치되어 있는 경우가 많을 것이다.

그렇다면, Appium의 가장 큰 특징은 무엇일까?

크로스 플랫폼을 지원한다는 점, 오픈 소스라 무료로 사용 가능하다는 점, 다양한 언어를 지원해 개발이 편리하다는 점 등의 많은 특징이 있지만, 내 생각에 가장 큰 특징은 아래와 같다.

 

⚙️ 자동화 테스트가 가능하다는 것이다.

Appium을 사용해서 애플리케이션의 사용자 인터페이스를 자동으로 조작하고 테스트할 수 있어 애플리케이션의 동작을 효과적으로 검증할 수 있다는 것이 가장 큰 특징이다.

그리고 내가 Appium을 사용하고자 하는 가장 큰 이유이기도 하다.

 

⭐️ Appium이 크로스 플랫폼을 지원하는 것이 왜?

Appium이 크로스 플랫폼을 지원하는 것은 굉장히 편리한 일이다. 진짜 미쳤다.

 

하나의 테스트 코드로 Android, iOS 모두 테스트 가능하다는 건데, 플랫폼이 달라져도 테스트 코드는 그대로 유지하면서 드라이버만 변경하면 다른 플랫폼도 테스트 할 수 있다는 것이다.

이게 가능한 이유는, Appium이 WebDriver 프로토콜을 사용해 플랫폼 간 공통된 인터페이스를 제공하기 때문이다.

• WebDriver Protocol
  : Selenium에서 유래된 표준화된 테스트 자동화 프로토콜로, "브라우저나 웹의 UI 요소를 어떻게 제어할 것인가" 에 대한 통신 규약을 정의

OS	🤖 Android	 iOS
UI 엔진	UIAutomator2, Espresso 등	XCUITest
실행 환경	ART(Android Runtime) 위에서 실행되며 실제 기기나 Android Emulator에서 동작	XNU 커널 기반의 iOS OS에서 실행되며 XCUITest 프레임워크를 통해 테스트됨. 시뮬레이터나 실제 기기에서 실행.
접근 방식	resource-id, content-desc 등	accessibility id, label 등

🎀 Appium Doctor

Appium을 설치하는 과정을 따라가다 보면, Appium Doctor를 설치하라는 경우를 많이 볼 수 있다.
Appium Doctor는 Appium을 실행하기 위한 개발 환경 구성 요소들이 제대로 설치되고 설정되었는지 검사하는 도구로, Appium을 실행하기 위한 환경이 정상적으로 구성되었는지 확인할 수 있도록 돕는다.

누락된 구성 요소나, 의존성 문제 등을 알려주기 때문에 초기 설정에 반드시 설치하라고 하는 편이다.

🎀 Appium Inspector

테스트 중인 모바일 애플리케이션을 시각적으로 검사하고 상호 작용할 수 있게 해주는 GUI(그래픽 사용자 인터페이스) 도구

 

테스트 자동화를 진행하다 보면, 화면 단위로 요소를 추출해 코드를 작성해야 한다.

기본적으로 내가 보고 있는 화면에서, 내가 테스트해야 할 요소에 어떻게 접근해야 하는지 "이름"을 알려주는 도구라고 생각하면 편하다.

요소에 접근하지 못하면, 테스트 자동화를 진행할 수 없다. 

 

Appium Inspector에서 요소에 접근할 수 있는 이름을 알려주는 방법은 ios 기준 크게 네 가지다.

Appium Inspector 화면의 오른쪽 부분을 보면, Find By 부분에서 요소의 접근 방법을 알려주고 있는 것을 확인할 수 있다.

ios class chain이나, ios predicate string은 iOS에서만 제공된다.

 

✨ accessibility id

모바일 UI 요소에 부여된 고유한 식별자로, 개발자가 직접 부여한 이름

• 다른 로케이터에 비해 요소를 찾는 속도가 가장 빠름
• UI 변경이 이뤄져도, 이름은 변하지 않아 UI 변경에 영향을 덜 받음
• accessibility id로 작성하는 것이 가장 권장되는 방법
• 하지만, 개발자가 직접 이름을 부여해줘야 한다는 점에서 개발자가 이 작업을 하지 않았다면, 사용할 수 없음

✨ ios class chain

iOS 전용 로케이터 전략으로, UI 요소의 **계층 구조를 기반으로 요소를 찾아냄.**

• XPath와 비슷하지만, iOS 고유의 문법을 사용하며, XPath보다 더 빠르고 안정적
• 직관적인 계층 표현으로 상, 하위 관계를 바탕으로 요소를 찾아냄
• name, label과 같은 Attribute로 필터링할 수 있음
• iOS에서만 사용 가능함

✨ ios predicate string

iOS의 NSPredicate 문법을 사용하여 요소를 찾는 방식으로, 하나 이상의 속성을 기반으로 요소를 필터링하여 찾을 때 유용

• attribute == 'value'와 같은 형태로 조건을 지정하며, AND, OR 같은 논리 연산자로 여러 조건을 결합할 수 있음
  • 위와 같은 특징으로, 복잡한 조건을 조합할 수 있어 매우 유연함
• 다양한 비교 연산자(CONTAINS, BEGINSWITH etc.)가 존재해 복잡한 상황에 사용하기 좋음
• iOS에서만 사용 가능하며, 문법이 다소 복잡함

✨ xpath

XPath는 XML 문서의 요소를 찾기 위해 고안된 언어로, Appium에서는 모바일 앱의 UI 구조를 XML 트리로 보고 요소를 찾음

• //XCUIElementTypeButton\[@name='로그인'\]처럼 계층 경로와 속성 값을 함께 사용하여 요소를 찾음
• iOS와 Android 환경에서 모두 지원함 (크로스 플랫폼 지원)
• 앞서 소개한 것들 중 가장 느리고, UI 계층 구조가 변경되면 xpath가 깨질 확률이 매우 높음

 

위와 같은 로케이터로, 요소에 접근할 수 있게 해주기 때문에 매우 필수적으로 설치해야 한다.

 

🎀 WDA(Web Driver Agent)

iOS 기기(아이폰, 아이패드 등)에서 UI 자동화 테스트를 실행하기 위해 Apple이 만든 XCUITest 프레임워크를 활용하는 오픈 소스 도구

 

간단히 말해, WDA는 Appium과 같은 외부 테스트 도구의 명령을 받아 iOS 기기 내부에서 실제 UI 조작을 실행하는 에이전트 역할을 한다.

 

테스트 코드(예: "버튼을 클릭하라")는 Appium 서버를 거쳐 WDA로 전달되고, WDA가 그 명령을 iOS 기기에서 실제로 수행하는 것이다.
WDA는 UI 테스트를 위한 API를 HTTP로 노출하여, HTTP 요청을 통해 UI 요소를 찾거나, 클릭, 스와이프 같은 동작을 실행할 수 있게 해준다.

 

🌼 WDA가 자동화 테스트에 필수적인 이유

 

• 브릿지(Bridge) 역할
  Appium은 컴퓨터(테스트 코드가 실행되는 기기)와 iOS 기기 사이에 직접적인 통신을 할 수 없다. 이때, WDA가 이 두 지점 사이의 "브릿지" 역할을 해주는 것이다. WDA는 iOS 기기 내부에 설치되어 외부의 명령을 받아 UI를 조작할 수 있는 유일한 수단이다.
• Apple의 공식 프레임워크 활용
  WDA는 Apple의 XCUITest 프레임워크를 기반으로 한다. XCUITest는 iOS에서 가장 안정적이고 효율적인 UI 테스트 프레임워크로, WDA는 이 프레임워크의 기능을 HTTP API로 외부에 제공함으로써, XCUITest를 직접 다루지 않고도 Appium을 통해 iOS 앱을 자동화할 수 있게 만드는 역할을 한다.
  
  • 만약 직접 XCUITest를 다뤄야 한다면, Swift나 Object-C와 같은 iOS 개발 언어를 직접 작성해야 한다. 이는 테스트를 위해 iOS 개발 지식을 따로 배워야 함을 의미한다.
  • 하지만, Appium 서버는 여기서 마치 통역사와 같은 역할을 한다. 개발자가 작성한 테스트 코드를 받아, WDA가 이해할 수 있는 HTTP 요청으로 바꿔 iOS 기기로 전달하는 역할을 해내는 것이다.

 

‼️ WDA가 정상적으로 실행되지 않으면, Appium Inspector를 실행할 수 없다. 왜?

Appium Inspector가 작동하려면 Appium 서버가 iOS 기기와 연결되어야 하는데, 이때 WDA가 그 연결을 담당한다. 앞서 설명한 브릿지 역할을 하는 것이다.

 

WDA가 iOS 기기 내에서 실행되며 UI 구조와 요소 정보(XML 트리)를 Appium 서버로 보내줘야 Inspector가 화면에 내용을 띄울 수 있다. 따라서 WDA가 실행되지 않으면, Appium 서버는 iOS 기기로부터 어떤 UI 정보도 받을 수 없다. (마치 TV가 셋톱박스(WDA)와 연결되지 않아 아무 채널(UI 정보)도 수신할 수 없는 것과 같다.)

 

이러한 이유로 WDA가 제대로 작동하지 않으면 Appium Inspector도 화면을 불러올 수 없게 되는 것이다.

 

요약하자면, WDA는 Appium과 iOS 기기를 연결하는 핵심 에이전트이며, 이 연결이 끊어지면 자동화 테스트는 물론, UI 요소를 탐색하는 Inspector 기능도 사용할 수 없게 되는 것이다.

 

---

위와 같은 이유들로, Appium을 통한 자동화 테스트를 진행하기 위해 설치해야할 것들이 생각보다 많다.

특히나 Apple 생태계는 폐쇄적이기 때문에, 테스트를 위해 Mac OS가 반드시 필요하다는 등의 제약 조건이 붙는다.

 

Appium 서버를 띄우고, Appium Inspector를 사용하고, WDA를 이용하면서 정작 왜 필요한가? 어떤 역할을 하는가? 에 대한 정리가 부족한 것 같아 같이 공부하자는 차원에서 정리해보았다.

 

본 글은 앞으로 더 디벨롭 될 가능성이 있다!