Android Testing ด้วย Cucumber และ Appium

ปัจจุบันการทํา automation test กับ application ต่างๆมีความหลากหลายมากๆ ทั้งภาษาหลากหลายแบบ และ เครื่องมืออีกเป็นจํานวนมาก ซึ่งวันนี้เราจะมาเรียนรู้เครื่องสุดฮิตกันซึ่งนั้นก็คือ Appium, Cucumber โดยจะใช้ภาษา Java เป็น client นั้นเอง 🙂

Cucumber VS Robot Framework

ถ้าใครติดตามบล๊อคนี้บ่อยๆจะเห็นว่าได้มีการเขียนถึง Robot Framework ค่อนข้างมากเลย ซึ่งจริงๆแล้ว แค่ละเครื่องมือมันสร้างมาด้วยจุดประสงค์แตกต่างกัน เช่น ช้อนก็ไว้ตัว ซ้อมก็ไว้เสียบ มีดก็ไว้หั่น การที่เอาบางอย่างมาเทียบกันแล้วบอกว่าอันดีกว่ากันจะค่อนข้างยาก เช่น มีคนถามว่ามีดดีกว่าช้อนมั้ย ถ้าคนตอบ จําเป็นต้องใช้การหั่น มันก็ต้องตอบว่าดีกว่า ในขณะที่ถ้าอีกคนต้องใช้การตักก็ต้องดีกว่าอยู่แล้ว มันก็จะเถียงกันไม่จบ

มาถึงเรื่องของ Cucumber, Espresso และ Robot Framework ก็เหมือนกัน เราไม่จําเป็นต้องบอกว่าอันไหนดีกว่า แต่มาดูกันว่าแต่ละอันแตกต่างกันยังไงดีกว่า?

Robot Framework

เจ้าประจําของเราเนอะ เจ้าตัวนี้มันถูกสร้างขึ้นมาเพื่อ Acceptance testing and acceptance test-driven development (ATDD) เป็นหลัก โดยใช้ keyword driven approach (text file based) เป็นหลัก หรือ กล่าวง่ายๆ คือ ATDD เป็นหลักการทําเทสโดยยึดข้อตกลงกับ Product Owner หรือ ลูกค้าว่าจะทําเทสออกมาในรูปแบบนี้ตั้งแต่เริ่มงาน ว่าถ้าผ่านตาม criteria พวกนี้ที่ define กันตอนก่อนเริ่มงาน หรือ sprint ถึงจะเรียกได้ว่าผ่าน และส่งมอบได้

ข้อดี ก็คือคนที่ใช้ robot framework อาจจะไม่ต้องมี technical knowledge มากนัก แค่เอา keywords ต่างๆมาผสมกันแค่นั้นก็สามารถเริ่มงานได้แล้ว แต่ข้อเสีย มันก็คือเรื่องของการ maintance กับ RBFW ก็มี cost ค่อนข้างสูงเลย ด้วยความที่เป็น text file based ก็ลําบากในการบริหารจัดการอยู่

Cucumber

ส่วนเจ้าตัวนี้มันถูกสร้างขึ้นมาเพื่อ Acceptance Testing เหมือนกับ Robot Framework เลย แต่ใช้หลักการของ Behavior driven development (BDD) แทน acceptance test-driven development (ATDD)

Tips:

ความแตกต่างระหว่าง ATDD กับ BDD เราต้องมาเรียนรู้ตั้งแต่ TDD ก่อนเลยยยยย 🙂

TDD = วิธีการทํางานแบบเขียนเทสก่อนเขียนโค้ด ให้มัน Fail ก่อนแล้วหลังจากนั้นเราค่อยเขียน Code เพื่อให้มันผ่าน ง่ายๆแค่นี้เลย เราทํายังงี้ไปเพื่อ “เราจะได้มั่นใจได้ว่า code ได้ผ่านการ test ตาม requirement จริงๆ” ซึ่งหลักๆเราก็โฟกัสกันที่ Single Class หรือ Method หรือง่ายๆคือ Low level นั้นเอง

ATDD = ที่นี้เจ้าตัวนี้ upside down เลย จากการมอง Low level แบบนั้น ATDD มองว่าเราควรจะ Test เพื่อให้ทุกคนเข้าใจจริงๆว่าเราเทสเพื่อทดสอบว่า “สิ่งที่เราต้องการจะทํา มันได้ถูก implemented” ตามที่เราต้องการจริงๆ เป็นการทํางานร่วมกับ Customer เอามาช่วย define ก่อนเริ่มเขียนโค้ด

BDD = แล้วถ้างั้นอะไร? คือ BDD? คํานิยามง่ายๆเลยน่ะ “โค้ดเรามันทํางานถูกอย่างที่มันควรจะทํามั้ย” คล้ายๆ TDD แต่มองเป็น component ที่ใหญ่ขึ้นมาหน่อย อารมณ์มองเป็น functional แทน Single Class เน้น Behavior of system แทน

พูดง่ายๆก็คือมองจาก Top-down ลงมาน่ะก็จะเป็นความกว้างๆ ATDD -> BDD -> TDD แบบนี้เลย

หลายๆคนบางทีก็สับสนว่ามันแตกต่างกันยังไง ระหว่างการใช้งาน RBFW และ Cucumber หลักๆแล้วเลยที่แตกต่างกันมากๆน่าจะเป็นเรื่องของ approach ในการ test โดยเจ้า RBFW จะเป็นการใช้ Keyword driven approach (text file based)

แต่เจ้า Cucumber จะเป็นการใช้ Feature File ขึ้นมา หรือ เรียกว่า Spec โดยเขียนโดยใช้ Style Gherkins Syntax หรือพูดง่ายๆก็คือ Given-When-Then  แล้วหลังจากนั้นก็เอาพวกนี้ไปเขียน Stpes ขึ้นมาอีกที

นี้คือตัวอย่างการเปรียบเทียบ Flow การทํางานระหว่าง Cucumber และ Robot Framework

ซึ่งจะมีผิดอยู่นิดหน่อยก็คือ RBFW ที่บอกว่าหลังจาก Keywords แล้วลงไปเรียก Test Lins เลย จริงๆแล้วในการทํางานจริง Keywords ไม่ได้ครอบคลุมทั้งหมด ยังไงเราก็ต้องเขียน Keywords ขึ้นมาเอง เพื่อให้เอาไปเรียกใช้เองอยู่ดีนั้นแหละ เพราะฉะนั้นออกมาแล้วมันก็คล้ายๆ Cucumber เพียงแต่ในระยะยาว RBFW text based มันเจ็บปวดกว่ามาก 🙂

Cucumber In Action

โม้เยอะล่ะ เสียเวลา 🙂 มาลองเล่นของจริงกันเลยดีกว่าเนอะ … ก่อนอื่นก็ไป clone repository นี้มาจาก Howtoautomate Github แล้วหลังจากนั้นมาลองเริ่มกับ Cucumber with Java กัน

Prerequsite

1. Inteillj Community Edition
2. Cucumber for Java
3. Example APK app
4. Android Studio (เอาไว้ build apk และ รัน emulator)
5. Appium Application 

โดยครั้งนี้สิ่งที่เราจะทําคือ Java client ทําการเขียน cucumber android testing ผ่าน Appium framework นั้นเอง โดยหลักๆจะใช้ gradle เป็นตัวจัดการ dependencies ตัวอื่นๆ และ ในการสอนครั้งนี้เราอาจจะต้องใช้ Apk ซักตัวเพื่อใช้ในการทดสอบระบบ โดยเราจะไม่ได้เน้นการเขียน test case เท่าไร เราเลยจะใช้ Apk อันเดิมที่เคยใช้ใน RBFW Android testing นั้นเอง 🙂 โดยจะ update APK ไปใน git ไว้เลย จะได้ง่ายๆ

Test Scenario

เนื่องจาก App demo นี้เป็น App ที่เรียกว่า Simple มากๆๆๆ แค่เปิดมาแล้วมีชื่อ Hello World ใน app เพราะฉะนั้นเราจะทําการเทสแค่ว่ามันมี  text นั้น display อยู่แค่นั้นเอง ถือเป็นอันเสร็จ 🙂

เพราะฉะนั้นหลังจากวิเคราะห์ Expected Behavior ได้แล้ว เราก็จะเขียนออกมาเป็นสไตล์ Gherkin ได้ว่า

Given I launch demo app

When The App opened

Then I see a welcome message "Hello World!"

แค่นี้เลย

Dependencies

เนื่องจากเราใช้ gradle ไม่ใช่ maven เราเลยไปเพิ่ม dependencies ใน build.gradle ให้มันเอาพวกสิ่งที่จําเป็นลงมาด้วย

Cucumber Code

ก่อนอื่นเราก็มาสร้าง Specs ไว้ใน folder test ก่อนเลย แล้วให้มัน Generate ออกมา ด้วย plugin ของ cucumber-java

ซึ่งสิ่งที่ต้องทําหลังจากเราสร้าง feature file แบบนี้แล้วก็คือไป implementation steps นั้นเอง … ลองนึกถึง flow ข้างบนที่เอามาเปรียบเทียบให้ดูอ่ะ นี้นคือขั้นต่อไป

โดยการ implement ตรงนี้จะคือจุดที่เราต้องไปเชื่อมกับ Automation Library อย่าง Appium แล้วนั้นเอง 🙂 แปลว่า Step @Given ที่เราเขียนเมื่อกี้ มันจะไปหาเจ้า Appium @When ก็เช็คพวก Screen ว่าเปิดขึ้น และ สุดท้ายก็ @Then ที่เช็ค String “Hello World” ว่ามันทํางานได้อย่างที่คาดหวังไว้

Setup Appium ก่อนไปเขียน Steps กัน 

expected result ของเราควรจะออกมาแบบนี้เลย 🙂

นั้นก็คือ หน้าจอ inspect ของ appium ที่ต่อกับ emulator ของ application เรา

คร่าวๆเบื้องต้นกับ appium ก่อนน่ะ … อยากให้มอง appium เป็นตัวกลางระหว่าง application เรากับ cucumber เป็นคนค่อยส่งข่าวสารไปให้กับ application ทํางาน

เพราะฉะนั้นสิ่งที่ต้องบอกคนกลางแบบนี้คือ จะส่งข่าวไปหาใคร? เค้าหน้าตาเป็นไง? ข้อมูลที่จะส่งเป็นแบบไหน? โดย appium เรียกสิ่งนี้ว่า Desired Capabilities นั้นเอง เพราะฉะนั้นสิ่งหลักๆที่ต้องทําก็คือกําหนดผู้รับให้ Appium แล้วให้มันติดต่อผู้รับเอง  ซึ่งจากตัวอย่างวันนี้ DCap ของเราก็จะออกมาหน้าตายังงี้

ถ้าถามว่ารู้ได้ไงว่าต้องใช้ package ไหน ก็ต้องบอกว่าเป็นเพราะเขียน package นั้นมาเองกับมือ เลยรู้ว่า directories ไหนยังไง?​แต่ถ้าได้ apk เปล่ามาๆ ก็ต้องพยายามหา appPackage เอา กับชื่อ deviceName ที่จะให้ appium ไปต่อนั้นเอง

แล้วเราจะเอาไปทําไรต่อ?

เราต้องเอา Dcap เหล่านี้ไปใส่ใน Steps ของเรานั้นเอง 🙂 เพราะจะได้เหมือน cucumber บอกให้ appium ไปต่อให้เราหน่อยน่ะ แล้วเราจะเอาค่าไปเช็คผลนั้นเอง

งั้นเริ่มจากสร้าง Class ใหม่ ชื่อ AppiumHelper ขึ้นมาเลย เพื่อเอาไว้ใช้ในการจัดการ Driver กับ Appium ซึ่งสิ่งที่เราทําก็ไม่ต่างอะไรจากเอาข้อมูลให้ Messenger เพื่อนําไปส่งให้ปลายทางนั้นเอง

ทีนี้หลังจากเรามีคนกลางแล้ว เราก็ไม่ต้องแคร์อะไรล่ะ ถามคนกลางอย่างเดียวตลอดเลย เจ้า AppiumHelper จะส่งข้อมูลไปถาม Application เราให้เลย โดยดูจากด้านล่างได้ จะเห็นว่า Steps ที่เราเขียนขึ้นมา จะทําการเช็คในส่วนของ Application ได้เปิดขึ้นมั้ยแล้วก็ไปเช็คดูว่ามี welcome message ตามที่เราอยากได้รึเปล่านั้นเอง?

ซึ่งต้องบอกเลยด้วย Appium version ใหม่เนี่ย ผมเองก็ไม่มั่นใจหรอกว่าใช้ UIAutomator ยังไงน่ะ แต่ดีที่มี appium guy เขียน integration test ไว้ใน github เลยทําให้สบายเลย ใช้ง่ายเลยทีนี้ …. ขอบคุณ Appium ครัช 🙂

ทีนี้พอกดรันก็จะเห็นว่าผ่านเป็นที่เรียบร้อย! เขียวสวยเลยล่ะ

สรุปแล้ว

ไม่ว่า RBFW หรือ Cucumber มันก็มีข้อเสียหลากหลายอย่างแหละ อยู่ที่เราเลือกว่าจะใช้ช้อนหรือส้อมมากกว่า 🙂

แล้วสิ่งที่ไม่ได้พูดซํ้าก็คืออันนี้เป็นแค่พื้นฐานของการใช้ Cucumber Java Client แต่เวลาเราเอาไปใช้งานจริง เรายังต้องเรียนรู้เรื่องของ Page Object ด้วย เพื่อที่จะได้ Manage test code ของเราได้ง่าย และ ไม่ DRY กับตัวเอง

แต่ไม่ว่าช้อนหรือส้อมครั้งนี้ก็ใช้อยู่บนจานเดียวกัน นั้นก็คือ จานของ Appium นั้นเองในการเขียน test บน device ยังมีอีกหลากหลายอย่างมาก เช่นใช้ Native เลยก็คือ Espresso Android ซึ่งน่าสนใจเหมือนกัน เพราะฉะนั้นครั้งหน้าไว้ครั้งหน้าจะมาเขียนเรื่อง Espresso Vs Appium น่ะ ดูว่ามันแตกต่างกันยังไง

Noted

• API list information android