feature-image-selenium-best-practices-should-know
feature-image-selenium-best-practices-should-know

การเขียน automation ก็เหมือนการเขียนโปรแกรม เราเองก็ต้องมี Best practices ในการเขียนการใช้งาน และต้องคํานึงการเขียนให้ได้ performance ดีที่สุด ไม่งั้นการทํา automation จะเป็น pain point สําหรับ Developer เวลาเค้าเอาไปใช้ และจะทําให้ไม่เกิดสิ่งที่เรียกว่า TRUST หรือความเชื่อใจกันและกัน

ส่วนนึงที่ทําให้เกิดปัญหาเรื่อง Performance มากที่สุดคือก็คือเรื่องที่จะเขียนต่อไปนี้ ถ้าเราทําตามสิ่งที่เป็น Best Practices ก็จะช่วยลดปัญหาไปได้ในระดับนึง

  1. Selector order
  2. Avoid Thread.sleep
  3. Relative URL & Dataset
  4. Use PageObjects Pattern

Selector Order

เมื่อเราเริ่มเขียน automation เราจะเห็นว่า document มันจะเขียนว่า ให้เราสามารใช้

  • element’s ID
  • element’s name / attribute / links / text
  • XPath Statement
  • document object model (DOM)

ทุกคนที่อ่านแล้วไม่ได้คิดต่อก็คงแบบ เห่ย คือดี มีให้ใช้เยอะฟระ ….. แต่ความเป็นจริงแล้วถ้าตอบยังงี้แสดงว่า ไม่เคยทํางานกับ Developer จริงๆแน่ๆ หรือ scale มันเล็ก ไม่ก็ควบคุมทุกอย่างได้ดีมากๆ

เพราะในความเป็นจริงแล้วการที่ใส่ ID ทุก elment เนี่ย หาได้ยากมาก เราต้องต่อรอง ไปขอให้ Dev. ใส่ให้ ซึ่งถ้าใส่ทุกอันยิ่งยาก เพราะเค้าก็ต้องทํางานเค้า แถมอาจจะมีตกหล่นด้วย หรือ statics เกินไป เราจึงเลือกจะใส่ในจุดที่ต้องใส่จริงๆเท่านั้น เช่น จุดที่ทําให้เกิด action นั่นเอง

ดังนั้นสิ่งที่เราควรเลือกในการใช้ Element Selector เลยก็คือ

ID > NAME > CSS > XPATH

เราควรที่จะให้ value ตามลําดับข้างบนเลย เวลาเราเลือกใช้ selector เพราะมันจะมีผลกับ Performance ของ tes ถ้าแรกๆอาจจะไม่มีผลอะไร แต่ในอนาคตมันอาจจะก่อให้เกิดปัญหาใหญ่ได้แน่ๆ

แต่ไม่ได้หมายความว่าเวลาใช้งานจริงๆ เราจะต้องใช้ตามลําดับนี้เป๊ะๆ ถ้าไม่ได้ เราจะลงไปดิ้นตายน่ะครับ ทุกตัวมีประโยชน์ในตัวของมันเอง

อย่าง Xpath ตัวยอดนิยมและเจ้าปัญหาสุด คือ มันเป็นตัวที่ดีในการจัดการ complex selectors มากๆๆๆๆ แถมมันยืดหยุ่นมากด้วย เช่น $x(“//*//td”) แบบนี้หมายถึงเอาทุก td เลยที่มัน display อยู่บนหน้าจอ! ฟังดูดีน่ะ….แต่ถ้าในหน้าจอเรามี td อยู่ 2 พันบรรทัดล่ะ

Xpath มันก็จะต้องทํา index ในรูปแบบ XML ก่อน แล้วค่อยดึงเฉพาะ td ออกมา ด้วยวิธีนี้จะทําให้มันเกิดปัญหาด้าน Performance ได้

ยังไม่นับรวมกับปัญหาที่เกิดกับตั้งแต่ IE 9 ลงไปด้วย ที่มีความเป็นไปได้ว่าจะเกิดปัญหา เพราะ IE ไม่ได้ทํา Xpath-over-html มา เหมือนเจ้าอื่นๆ จึงจําใจต้องใช้ JavaScript ในการประมวลผล Xpath ซึ่งมันช้าระดับวินาทีเลย

ดังนั้นจึงแนะนําให้ใช้ CSS มากกว่า Xpath (เพราะบางที element ไม่มี ID กับ name ด้วย ….. CSS เลยเป็นตัวเลือกที่ดีตัวนึงเลยล่ะ)

Avoid Thread.sleep

ปัญหาอีกอย่างนึงเวลาเขียน Automation กันคือ เวลาหน้าเว็ปมี action ของการ Loading หรือต้องรอการประมวลผล

เรามักจะนิยมใส่ Thread.Sleep กัน เพื่อให้มันรอ อาจจะแบบ 1-2 วิไรแบบนั้น ซึ่งบางทีมันก็ทํางานได้ดี บางทีก็ไม่ได้ดี แต่….เราจะมั่นใจได้ไงว่าเว็ปมันจะประมวลผลเสร็จแล้วในช่วงเวลานั้น ซึ่งการทํายังงี้ทําให้เกิดปัญหาได้แน่ๆ

 

เราจึงควรจะเลิกใช้


Sleep | 5

แล้วเปลี่ยนเป็น


${result} | Wait Until Keyword Success | retry | retry_interval | Keyword

FYI: Robot Framework Syntax น่ะครับ

ด้วยการที่เราขียนการ Wait แบบมี condition จะทําให้เราควบคุม Flow ของการทํางานได้ดี ว่า เกิด error ไปไหน หรือ success ไปไหน แบบนี้

Relative URLs & DataSet

จริงๆมันคือเรื่องของการอย่าทํา Hardcode มากกว่า ไม่ใช่แค่ relative urls เพียงอย่างเดียวหรอก เพราะบางทีเราชอบไป Fixed URL หรือ ข้อมูลบางตัว ไว้ในโปรแกรมเลย

ซึ่งการกระทําอย่างนี้มันจะทําให้เกิดปัญหาเมื่อ enviroment เปลี่ยนไป เช่นเปลี่ยนไปเป็นอีก URL นึง หรือข้อมูลเปลี่ยนไป ทําให้การไป Hard code เกิดปัญหาขึ้น

Use PageObjects Pattern

การใช้ PageObject Pattern กลายมาเป็นที่นิยมมากในการเขียน test automation เพราะว่ามันลดการ Duplicate code ลงได้เยอะมากๆ

Page Object มันเป็น Object Oriented class ที่ทําหน้าที่เป็นเหมือน Services Layer ที่จะไว้คุยกับ System ที่เราต้องการจะทําการ Test

ข้อดีของมันก็คือ เหมือน Applicatin Under Test มีการเปลี่ยน UI เราไม่ต้องทําการแก้ test code เราจะแก้เพียง code ที่อยู่ใน PageObject เท่านั้นที่ต้องแก้ การแก้ไขจะอยู่ที่เดียวไม่ยุ่งยาก

สรุปข้อดีชัดๆคือ

  1. Clean Separation ระหว่าง test code และ page ที่ต้องการ test (locator,layout,interact code)
  2. Single Repository of Services Page คือเราแยกกันขาด แล้วโค้ดที่ Interact แก้ที่เดียวนั่นเอง
  3. Reuseable มากๆด้วย เวลาเราเขียน test code ก็แค่ดึงแต่ล่ะ services มาร้อยเรียงกันนั่นเอง

สรุป

ลองทําตามสิ่งเหล่านี้ แล้วจะรู้ว่าชีวิตง่ายขึ้นเยอะๆเลย! แต่สิ่งสําคัญคืออย่าลืมวัดผลจากการเปลี่ยนแปลง เพราะทุกการเปลี่ยนแปลงถ้าเราปล่อยผ่าน เราจะไม่มีวันรู้เลยว่ามันดีจริงไม่ดีจริง

Leave a Reply

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.