簡介
Dogtail 是基於 Python 圖形介面自動化測試工具，透過 Accessibility / AT-SPI（Assistive Technology Service Provider Interface，輔助技術服務提供介面）與桌面應用程式互動。
環境
以下是適用於 Rocky Linux 8 以及 Fedora 40。
小提醒：我的環境比較老，適用安裝版本是 dogtail 1.0.8，實際上在更新本篇文章時候 dogtail 已經更新至 2.0.3，建議還是要評估一下開發環境。
所需套件
| 名稱 | 說明 | 採用版本 |
|---|---|---|
| dogtail | 使用 AT-SPI accessibility framework 檢查並操作 Linux 桌面應用程式的 GUI 自動化工具。 | 1.0.8 |
| pytest | 用於撰寫與執行自動化測試案例的 Python 測試框架。 | 6.2.5 |
| pytest-xdist | pytest 外掛，支援平行與分散式測試執行。 | 2.5.0 |
| pycairo | Cairo 2D 繪圖函式庫的 Python binding，通常作為 GTK 相關相依套件所需元件。 | 1.20.1 |
| pygobject | GObject-based 函式庫的 Python binding，包含 GTK 與 AT-SPI 整合能力。 | 3.38.0 |
| dbus-python | D-Bus 的 Python binding，用於 Linux 桌面環境中的行程間通訊。 | 1.2.18 |
相依套件
Headless GUI 執行環境
- xorg-x11-server-Xvfb：提供 headless X server，讓 GUI 程式可以在沒有實體螢幕的環境中執行。
- dbus-x11：提供 X11 session 下的 D-Bus 支援，AT-SPI 需要透過 D-Bus 進行溝通。
- at-spi2-core：提供 Accessibility / AT-SPI 核心服務，dogtail 需要透過它讀取與操作 GUI。
- gnome-ponytail-daemon：dogtail 1.0.x 需要的 Ponytail daemon，用於 GUI input automation。
- python3-gnome-ponytail-daemon：提供 Python 端的 ponytail module，dogtail 在 import ponytail.ponytail 時需要使用。
其中 gnome-ponytail-daemon 和 python3-gnome-ponytail-daemon 在 Rocky Linux 8 似乎無法順利安裝，所以請自行斟酌。
Python 執行與測試環境
- python3-gobject：提供 Python 存取 GObject / AT-SPI 相關 introspection API 的能力。
- python3-dbus：提供 Python 與 D-Bus 溝通支援，GUI automation 環境通常會需要。
Python source build 相依套件
- llvm-devel：提供 clang / LLVM 相關開發工具與 llvm-profdata，供 Python –enable-optimizations 使用。
- openssl-devel：用於編譯 Python _ssl module，使 pip 可以透過 HTTPS 安裝套件。
- zlib-devel：用於編譯 Python zlib 支援，供壓縮與套件安裝使用。
- bzip2-devel：用於編譯 Python bz2 module。
- sqlite-devel：用於編譯 Python sqlite3 module。
- libffi-devel：用於編譯 Python ctypes module，也常被 PyGObject 相關套件使用。
- readline-devel：提供 Python interactive shell 的 readline 支援。
- xz-devel：用於編譯 Python lzma / xz 支援。
- ncurses-devel：提供 terminal 相關功能支援。
- gdbm-devel：用於編譯 Python dbm / gdbm 相關 module。
- tk-devel：用於編譯 Python tkinter module。E2E 不一定直接需要，但建議 Python source build 時一併安裝。
- libuuid-devel (or uuid-devel)：提供 UUID 相關 native library 支援。
Native package build 相依套件
- pkg-config：用於讓 native package build 時找到 cairo、gobject-introspection、dbus 等開發套件。
- gobject-introspection-devel：提供 gobject-introspection-1.0.pc，PyGObject 編譯時需要。
- cairo-gobject-devel：提供 cairo-gobject.pc，PyGObject 編譯時需要。
- cairo-devel：提供 cairo native headers / libraries，pycairo 編譯時需要。
- dbus-devel：提供 D-Bus native headers / libraries，dbus-python 編譯時需要。
- at-spi2-core-devel：提供 AT-SPI 開發檔案，供相關 accessibility binding 或 native dependency 使用。
所有套件的安裝指令
sudo dnf install \
xorg-x11-server-Xvfb \
dbus-x11 \
at-spi2-core \
python3-gobject \
python3-dbus \
llvm-devel \
openssl-devel \
zlib-devel \
bzip2-devel \
sqlite-devel \
libffi-devel \
readline-devel \
xz-devel \
ncurses-devel \
gdbm-devel \
tk-devel \
libuuid-devel \
pkg-config \
gobject-introspection-devel \
cairo-gobject-devel \
cairo-devel \
dbus-devel \
at-spi2-core-devel \
gnome-ponytail-daemon \ (Rocky Linux 8 似乎無法安裝)
python3-gnome-ponytail-daemon \ (Rocky Linux 8 似乎無法安裝)驗證方式
可先透過以下方式確認系統相依套件是否足以支援 Python 測試環境建立。
python3 -m venv test-venv
source test-venv/bin/activate
pip install \
dogtail==1.0.8 \
pytest==6.2.5 \
pytest-xdist==2.5.0 \
pycairo==1.20.1 \
pygobject==3.38.0 \
dbus-python==1.2.18若上述指令可成功完成，表示目前所需的 Python 測試套件與 native build dependency 已可正常安裝。
驗證完成後可離開並刪除 temporary venv。
deactivate rm -rf test-venv背景補充
Accessibility / AT-SPI 是什麼？
Accessibility 又可以被縮寫為 A11y，在軟體的語境可直翻「無障礙存取」，或也可以採用「可及性」的概念，也就是說讓不同使用者，包含使用螢幕閱讀器、鍵盤操作、輔助工具的人，都能理解並操作介面。
例如說：
- 一個按鈕不會只是一顆實體按鈕，它本身要有可以讀的名稱。
- 圖片不能只有圖片，而是要有文字描述。
- 介面是否可以只用鍵盤操作？（而不是只能用滑鼠）
- 顏色對比是適合顏色辨識障礙的人區分嗎？
AT-SPI 全名是 Assistive Technology Service Provider Interface，如中文「輔助技術服務提供介面」，指的是 Linux 桌面環境裡的一套 accessibility 介面。
在 GUI 測試脈絡裡，這方面主要是應用程式把 UI 元件用可被外部工具讀取的方式暴露出來。所以 accessibility 的設計，不只是給輔助工具使用，也常被拿來做 E2E GUI 自動化測試。簡單來說就是要讓 GUI 應用可以「被看見」和「被操作」。
以 dogtail 這類工具來說，它就是透過 AT-SPI 去找到 UI 元件並且操作他，也就是說測試不直接呼叫 internal API，而是像使用者一樣透過 GUI accessibility tree 操作畫面，黑箱就是這個意思 = =+
為什麼會用這套工具
跨平台 GUI 測試方案主要是模擬真實 user 的操作，所以比起 unit test 或是 integration test 難點在於說需要能夠有物件辨識的能力。最常被提及應該是 Squish、Sikulix 以及 CukeTest 等。我平常使用 Qt 框架開發桌面應用，在評估 E2E 測試方案時，首要選擇通常會是 Qt 官方推薦的標準工具 Squish。
Squish 是一款商業化的跨平台 GUI 和回歸測試工具，但它要收費（而且印象中不便宜）。但 Qt 團隊其實算大方，Squish 試用期很短，我們團隊多次向 Qt 團隊延長試用期限以作為評估，最終似乎延了半年多吧哈哈，主要是臉皮夠厚。但後來還是因為小團隊實在負擔不了，因此不了了之。
CukeTest 在 AI 時代開發可能會相對優勢的是它支援 BDD（行為驅動開發），能以自然語言撰寫測試案例。但我們團隊的開發流還不適用，所以就比較沒有再研究下去。不採用 Sikulix 是因為評估期間遇到蠻棘手的環境問題，可能就八字不合吧哈哈所以後來也沒有再繼續考慮。
總而言之就是團隊不可能在無法評估效益的狀況下就花大錢去買服務，最終就找上了 dogtail，至少是專為 Linux 系統設計的 GUI 測試與自動化框架。
後記
當初會挑這個工具，主要是看上他可愛的名字：dogtail。而且不只名稱可愛，它用來檢查 UI 元件 accessibility 資訊的工具叫做 sniff，中文是嗅聞、嗅探，很可愛哈哈哈哈，感覺真的有一隻小狗狗在我的環境跑來跑去。
在找資料時，意外發現到內容豐富的網站：A11y 新手村，蠻喜歡這個組織的理念，改天看有沒有機會參與貢獻。
