Posted on July 9, 2015 By Anak Umpaivit
Capybara Test Cases
แน่นอนว่า สิ่งที่ขาดไม่ได้สำหรับการทำ Automated test ก็คือ Test Scenario หรือ Test Cases นั่นเอง ซึ่งโดยปกติแล้ว Tester ส่วนใหญ่ก็น่าจะมีวิธีการออกแบบวิธีการ Test อยู่แล้ว อย่างการทำตาราง Given, When and Then เป็นต้น แต่ในการเขียน Capybara นั้น เราก็ต้องนำ Case ต่างๆ มาแยกเป็นข้อๆ และเขียนลงไปเช่นกัน แล้วจะเขียนยังไงดี? เขียนยังไงถึงจะถูก? เป็นคำตอบที่ตอบได้ยาก แต่จากประสบการณ์ของตัวผู้เขียนเอง ที่ผ่านการลองผิดลองถูกมาพอสมควร จะมาเสนอเทคนิคที่ใช้อยู่ในปัจจุบันให้ฟัง แต่ก่อนอื่น เราต้องมาดูก่อน ว่า Capybara นั้น มีรูปแบบการเขียน Test Cases ยังไง
รูปแบบการเขียน Cases ของ Capybara
หลักๆ แล้ว ที่ผมใช้อยู่ปัจจุบัน จะเขียนในรูปของ
[code language="ruby"]
describe "A dog" do
it "can walk" do
...
end
it "can bark" do
...
end
end
[/code]
ซึ่งใน QA ที่ใช้งาน Capybara บางคน อาจจะไม่ได้ใช้งานคำว่า Describe และ it แต่จะใช้คำว่า Scenario และ Context แทน ก็สามารถใช้งานได้เหมือนกันแล้วแต่ความชอบของแต่ละคน แต่สำหรับผม เลือกใช้แบบนี้แล้วรู้สึกสั้นและกระชับอ่านได้ง่ายกว่านั่นเอง และจาก code ด้านบน ผมยกตัวอย่างง่ายๆ ของการทำงานให้ดูว่า สุนัข -> สามารถเดินได้ และ สุนัข -> สามารถเห่าได้ แต่ถ้าเกิดมันซับซ้อนกว่านี้ล่ะ? เราก็สามารถแบ่งย่อยเข้าไปได้อีกด้วย Describe เช่น
[code language="ruby"]
describe "A dog" do
describe "legs" do
it "can walk" do
...
end
it "can scratch" do
...
end
end
describe "mouth" do
it "can bark" do
...
end
it "can eat" do
...
end
end
end
[/code]
จะเห็นได้ว่า เราสามารถเขียนแยกย่อยเข้าไปได้เพื่อเช็คในแต่ละส่วน.. แต่ถ้าสังเกตุดู ถ้ามันใช้งานได้ปกติ เราก็จะไม่รู้ว่ามันใช้งานได้ปกติเพราะอะไร หรือถ้าเกิดวันใด มันทำงานผิดพลาด และแสดงออกมาเมื่อ Run Test เราก็ไม่รู้ว่า มันผิดที่อะไร เรารู้แค่ว่า มันเดินได้ หรือไม่ได้ มันกินได้ หรือไม่ได้ แต่ไม่รู้ว่า มันเกิดอะไรขึ้น มันถึงผิดพลาด และต้องไล่ code ดูว่าเราเคยเขียน check ไว้ว่าอย่างไร เพราะฉะนั้น เราควรจะเขียนอธิบายเพิ่มลงไป เช่น
[code language="ruby"]
describe "A dog" do
describe "legs" do
it "move to forward when it walk" do
...
end
it "shake when it scratch" do
...
end
end
describe "mouth" do
it "make sound when it bark" do
...
end
it "chew when it eat" do
...
end
end
end
[/code]
เพราะฉะนั้น หากเกิดความผิดพลาดขึ้น เราก็สามารถตรวจสอบได้ง่ายขึ้น เพราะแค่อ่านประโยคที่ Fail เราก็สามารถเข้าใจได้ทันที เช่น หาก case ของการเห่า หรือ bark เกิด Fail ขึ้นมา Terminal ที่เรา Run test จะแสดงประโยคว่า "A dog mouth make sound when it bark" เราก็สามารถรู้ได้ทันทีว่า มันผิดปกติเพราะมันไม่มีเสียงออกมานะ เมื่อเรารู้ปัญหาได้ไว เราก็สามารถแจ้งแก่ Developer ให้แก้ไขได้อย่างรวดเร็ว
แล้วถ้าเราไม่เขียนแบบนี้ละ? เราลองมาดูถ้าเราเขียน case เหมือนตอนแรก แล้วเกิดปัญหาที่การ bark มันจะแสดงประโยคว่า "A dog mouth can bark" เราจะรู้ว่า มันเห่าไม่ได้นะ แต่เราไม่รู้ว่า ทำไมมันถึงบอกว่า เห่าไม่ได้ เราต้องมานั่งไล่ code ใน case ที่ Fail ดู ว่าเราเขียนอะไรไว้เพื่อเช็คการเห่าของหมาน้อย ซึ่งถ้าเป็น Story จริงๆ มันอาจจะดูไม่ง่ายแบบนี้แน่ๆ เพราะการทำงานของ Web Application หลายๆ อย่าง ค่อนข้างซับซ้อน และการพัฒนาต้องใช้เวลา เมื่อเกิดความผิดพลาดขึ้นเมื่อเวลาผ่านไป เราอาจจะลืมไปแล้วก็ได้ ว่าเราเคยเขียนอะไรไว้ เพราะฉะนั้น Describe กับ It ที่ดี ก็จะช่วยให้เรา Inspect ปัญหาได้ง่ายขึ้นนั่นเอง
ข้อมูลที่น่าสนใจ