Cưỡi React Native xem Appium (Phần 1 – Cùng tìm hiểu cách hoạt động của Appium)

Tram Ho

1. Mở đầu

Do dòng đời đưa đẩy và khách thì tiền ít nhưng lại thích hít hàng thơm (toàn đòi 80~100 coverage -_-) nên mình cũng đã kinh qua react-native-testing-library một thời gian kha khá, và cũng nghịch thử Detox, nhưng chưa thằng nào làm mình hài lòng:

  • Testing-library: Khi test e2e thì phải mock quá nhiều, khá khó để mock component sao cho hoạt động giống như component thật. Có những lúc mình chỉ viết để cho % coverage lên chứ các fn của test đó bị mock hết, thành ra chả có ý nghĩa gì nhiều. Các thành phần UI bị mock hết, nên test pass mà vẫn chết là điều bình thường như cân đường hộp sữa.
  • Detox: chơi với mỗi simulator, device thật ko rõ tới giờ đã được đánh điện tử chưa.

Và gần đây thì mình đọc lại docs của React Native có recommend thêm 1 thằng – Appium. Appium sử dụng driver như XCUITest, UIAutomator, Espresso, … Được các teito (tay to :v) native ở công ty bảo mấy thằng driver trên toàn là hàng hịn bên native dùng để chạy test, nên thử nghịch luôn. Sau một thời gian mày mò thì khá hài lòng.

Tại sao lại dùng Appium mà ko chạy cơm cho khỏe?

Nói thế chứ thực ra thì chạy cơm không hề khỏe tí nào đâu các bạn.

Khi ta phát triển 1 feature mới cho app, ta phải test cho cả những tính năng đã có, ảnh hưởng tới chúng là điều khó tránh khỏi.

Thông thường dev chúng ta sẽ nghĩ là “Có tester rồi xoắn gì” đúng không nào? Tuy nhiên phận dev quèn thì cũng vẫn phải check qua những case cơ bản, (test thêm case dị càng tốt) trước khi chuyển qua cho tester. Nhưng không lẽ cứ viết một feature là ngồi bật app lên bấm từng nút, chưa kể xe đạp mới ( mình có một người bạn rất hay nhầm newbie và newbike =)) ) newbie không nắm rõ hệ thống, lack case là điều tất nhiên, hơn nữa con người chúng ta không giỏi trong những việc nhàm chán có tính lặp lại cao như test app, vì vậy dù có là bô lão thì cũng sẽ có lúc nhầm lẫn.

Ngoài ra, ở cuốn “The Effective Engineer” của Edmond Lau (nếu ko có gì sai sót thì là trang 159) có viết:

If you have to do something manually more than twice, then write a tool for the third time

Vậy thì sao chúng ta không để máy làm những công việc nhàm chán như test, và focus vào những việc khiến ta hứng thú hơn. Hãy cùng học viết test tự động cho ứng dụng React Native của chúng ta thôi nào!

Một vài kiến thức cần có

  • React Native, Babel (không cần quá mát tơ)
  • Nắm được cơ bản về viết unit test (với jest, hay gì đó tương tự)
  • Typescript (optional): do ở bài viết sẽ dùng Typescript

Hardware

  • Máy Mac/Hackintosh để build iOS hoặc máy Win (chỉ chạy được Android thôi)
  • 1 con điện thoại iOS hoặc Android – nói không với integration test trên simulator :v

2. Chạy thử ví dụ nhỏ

Tự dưng nhồi một đống lý thuyết suông, trong khi không biết mình sẽ làm gì có phải rất chán không nào? Vì vậy trước tiên ta hãy chạy thử một ví dụ nhỏ sau trước đã: Đăng kí account

Ví dụ sau dùng Typescript + WebdriverIO, và có cấu trúc tương đương với ví dụ trên trang chủ của Appium link (Các bạn cũng có thể vào link trên bằng truy cập trang chủ Appium rồi bấm vào nút Examples), tất nhiên để go pro thì ta sẽ ko code như vậy, mình sẽ thực hiện refactor và chuyển đổi môi trường chạy test ở các bài sau ( nếu có =)) ).

Sau khi setup Babel cùng với Jest (do Jest luôn đi kèm với React Native nên mình dùng luôn để demo cho thân thiện), hãy viết 1 đoạn test đơn giản cho quá trình sign up của ta.
Hiện tại mình chỉ fill những field text input, vì field select, date picker viết khá dài, nên mình sẽ đề cập sau.

Nói nhiều quá, code đâu?

Vâng, code đây (ở dưới có giải thích code)

Chi tiết source code có thể xem tại đây

Source code của các màn hình có thể xem tại đây:

  • Login screen link
  • Registration screen link

Và đây là thành phẩm:

iOSAndroid

Ví dụ trên làm gì?

  1. Từ màn Login, bấm vào button 「Create an account」 login/toRegistrationScreenButton để vào màn Registration

  2. Tại màn Registration

    1.1.Bấm vào nút 「Register」registration/registerButton, do máy Android của mình màn hơi ngắn, nên trước khi click phải scroll tới element đó trước.

    1.2. Do chưa fill gì nên expect error message hiển thị tương ứng

    1.3. Fill 「user..01」vào input username, do field này chỉ nhận alphabet và số, nên giá trị đó ko hợp lệ, expect hiển thị error message

    1.4. Fill username 1 giá trị hợp lệ 「user」

    1.5. Fill password 「password」

    1.6. Fill password confirmation「password123」, do ko match password đã nhập nên sẽ hiển thị error

    1.7. Fill password confirmation hợp lệ 「password」

    1.8. Fill full name

    1.9. Bấm vào nút 「Register」

  3. User được chuyển qua màn RegistrationCompleted, nên ta expect button ở màn này được hiển thị.

Phân tích một vài note về cú pháp

Cú pháp của WebdriverIO nhìn khá trong sáng và dễ hiểu, nên mình sẽ không giải thích nhiều, tuy nhiên có một vài chú ý dưới đây cho các bạn.

  • Khi tìm element, mình đã dùng ~, đây là shorthand để tìm element theo accessibility id của WebdriverIO, tuỳ theo OS mà ta sẽ phải gán prop khác nhau để có thể dùng được strategy tìm theo accessibility id này link, chỉ vì cái này mà mình mất vài tiếng, ko hiểu tại sao ko tìm thấy element =))

    • Ở bên iOS ta phải dùng testID, và tránh gán accessibilityLabel và accessibilityHint cho component.
    • Ở bên Android, hãy dùng accessibilityLabel
    • Các bạn có thể tham khảo các strategy khác ở docs của webdriverio link

  • Tại sao lại dùng accessibility id mà không dùng content của nó?

    • Đúng ra là khi bấm button hay thao tác trên màn hình, chúng ta nên dùng text của nó, để khi text (requirement) thay đổi thì test cũng oẳng. Nhưng mà cơ bản là do hơi bận lười =)) và trường hợp accessibility id đúng nhưng text sai thì phải chấp nhận thôi à =))

  • Do API của WebdriverIO toàn trả về Promise, nên hầu như câu lệnh nào cũng cần phải dùng async/await, các bạn có thể sử dụng kèm package @wdio/sync để API của WebdriverIO trở nên đồng bộ.

  • Các bạn có để ý đoạn code ở beforeEach và afterEach không? Mỗi test, chúng ta đang tạo ra một session mới, và xoá session đó sau mỗi test. Nếu dùng CLI của wdio thì sẽ thuận tiện hơn.

  • Options xcodeOrgId và xcodeSigningId bên trong capabilities của RemoteOptions iOS

    • Để chạy test trên thiết bị iOS, Appium sẽ cài một phần mềm tên là WebDriverAgent lên thiết bị, và để cài đặt được, ta phải cung cấp developer team và signing certificate.

      Các bạn có thể xem thêm tại đây link

  • Đối với thiết bị thật thì ta cần thêm UUID, có thể xem cách tìm UUID tại đây

  • capabilities của Android

    • Để lấy deviceName, hãy chạy adb devices

    • com.learnrne2etest và .MainActivity có thể lấy từ android/app/src/main/AndroidManifest.xml

      Hoặc tham khảo bài sau link

Cưỡi ngựa xem hoa như vậy đủ rồi, chúng ta hãy cùng tìm hiểu thêm về cách hoạt động của Appium

3. Kiến trúc, flow của Appium

Appium dựa trên kiến trúc client-server, bản thân Appium là 1 server, có thể dễ dàng nhận thấy điều này ở đoạn config.

3.1. Test library + WebDriver client

Khi viết test, ta sẽ dành phần lớn thời gian để làm việc với chúng, như ví dụ ở phần 2, ta đã sử dụng Jest (với các câu lệnh it, describe, afterEach, afterAll) là công cụ để chạy test, và WebdriverIO (với $, click(), setValue(value)) để giao tiếp với Appium server.

Ngoài bộ đôi này, chúng ta có thể sử dụng bất cứ ngôn ngữ nào mà ta thích (miễn là Appium nó support :v), từ Ruby, Python cho đến PHP, C#, có thể xem list tại đây

Nhưng mà mình recommend combo sau:

  • Ngôn ngữ: JS/TS thân thiện với React Native dev

  • WebDriver client: WebdriverIO vì trong đám client, thằng này nhiều star trên github nhất =))

  • Test library: jasmine
    • Vì nó có cú pháp giống Jest, mà anh em code React Native thì quá quen thuộc với Jest rồi
    • Là 1 trong 3 test framework được WebdriverIO support sẵn để go pro =)) (ngoài ra còn có mocha và cucumber), dùng Jest nếu lỗi thì phải tự mày mò thôi :v

Như đã nói ở trên, Appium áp dụng kiến trúc client-server. Khi ta viết những câu lệnh sau

nếu để ý log ta có thể thấy những dòng log dưới đây, webdriverio chỉ đơn thuần gửi 1 HTTP request tới server, server làm gì thì chúng ta sẽ tìm hiểu sau :v

  • iOS

  • Android

3.2. Appium server, Automation tool, Devices

Đây là phần xương sống trong kiến trúc của Appium, nó đảm nhận việc handle request từ client, giao tiếp với native automation tool để thực thi những command mà ta cần.

Appium server expose ra API theo chuẩn JSON Wire Protocol (WebDriver Protocol). Tuỳ vào target là iOS hay Android, nó sẽ có cách hoạt động riêng để phù hợp với nền tảng đó.

3.2.1. Appium meets iOS

Quay trở lại đoạn log ở phần 3.1, nó đã ít nhiều gợi ý cho ta cách hoạt động của Appium

Có thể dễ thấy Appium server đơn giản chỉ proxy request của ta tới 1 server khác chạy ở port 8100 http://127.0.0.1:8100.

Oát dờ phước? Thằng nào đang chạy ở port 8100 vậy?

Đó là WebDriverAgent server, ban đầu được phát triển bởi ông lớn Facebook, appium đã fork về thêm mắm thêm muối gì đó vào.

WDA giúp giao tiếp với XCUITest để có thể điều khiển device/simulator iOS từ xa. Bản thân nó cũng đã support sẵn Webdriver Protocol, vậy nên chắc hẳn dev Appium đã nghĩ như sau

Tội gì mà phải code lại, có sẵn hàng ngon rồi thì dùng luôn thôi =))

WDA làm gì với device thì mình xin skip, vì cũng ko biết =)) Các bạn có thể tự mình tìm hiểu sâu hơn nếu có hứng thú với nó.

3.2.2. Appium meets Android

Với Android, ta có ít gợi ý hơn

Không thấy proxy gì đó phải không nào? Đúng vậy, vì nó có proxy đâu :v

Ở version mới nhất, Appium sử dụng appium-android-driver để giao tiếp với UIAutomator2. Vậy giao tiếp thế nào?

Mỗi khi bắt đầu chạy test, Appium sẽ cài app Appium Settings trên device của ta, thằng này sẽ mở port 4724 trên device của ta và expose ra một vài API hệ thống. Appium server abc với app đã cài trên (qua HTTP), và nó sẽ xyz với UIAutomator2 để thực hiện các command.

4. Kết luận

Là một dev, chúng ta không được chủ quan, lệ thuộc vào bên tester, mà hãy tự mình kiểm thử trước khi chuyển qua cho họ. Test chạy cơm là một công việc nhàm chán, vậy thì tại sao chúng ta không làm cho nó thú vị hơn bằng cách automate nó. Tuy sẽ có lúc cần một số thủ thuật, hay là phải dùng nhiều command khá lằng nhằng ( như cái datepicker chẳng hạn =)) ), nhưng một khi chạy được nhất định nó sẽ đem lại cho các bạn một cảm giác phê như con tê tê =))

Code e2e của bài viết chỉ là những đoạn code tạm bợ, các bạn muốn go pro có thể tham khảo appium-boilerplate của webdriverio về cách chia module, cũng như setup project. Nếu có thời gian mình sẽ viết thêm về việc refactor đống code tạm bợ trên để go pro =)) Giờ thì xin tạm biệt các bạn.

Chia sẻ bài viết ngay

Nguồn bài viết : Viblo