เริ่มต้นเขียน Automation Test กันดีกว่า

มีโอกาสแบ่งปันเรื่องการทดสอบระบบงานแบบอัตโมมัติ (Automation Test) ทั้ง Web, API และ Mobile ใช้การทดสอบเป็นตัวหลักในการขับเคลื่อนการพัฒนา software เป็นสิ่งที่สำคัญและขาดไปไม่ได้เลย ช่วยทำให้เรามีความเชื่อมั่นต่อ code ที่เขียน อีกทั้งลดความกลัวจากการแก้ไข และช่วยให้เรากล้าทดลองทำในสิ่งใหม่ ๆ อีกด้วย แต่สำหรับการเริ่มต้นมันไม่ง่ายเลย จึงทำการสรุปสิ่งที่ควรจะรู้ไว้นิดหน่อย

กฏการเขียนชุดการทดสอบ โดยเฉพาะ Unit test ที่ดี

แต่ละ test case ต้องทำงานได้รวดเร็ว ในปัจจุบันต้องอยู่ในหน่วย nano/millisecone กันไปเลย ถ้าใครยังเป็นระดับวินาทีน่าจะผิดทาง ลองปรับกันดู ในแต่ละ test case ต้องเป็นอิสระแก่กัน นั่นคือแต่ละ test case จะไม่เกี่ยวข้องกัน ทำให้สามารถทดสอบแบบสุ่ม และ แบบขนานได้อีกด้วย แต่สิ่งที่พบเจอเป็นประจำคือ ผลจาก test case ที่ 1 เป็น input ของ test case ที่ 2 ผลจาก test case ที่ 2 เป็น input ของ test case ที่ 3 และ .... ถ้าเป็นแบบนี้บอกได้เลยว่า น่าจะมาผิดทาง เนื่องจากแต่ละ test case ผูกมัดกันไปหมด และต้องทำงานแบบเรียงลำดับกันด้วย จะไม่มีการทำงานร่วมกับระบบ Network และ Database ใด ๆ ทั้งสิ้น ถ้าทำงานด้วยน่าจะเป็น Integration หรือไม่ มันช้า !! และมักจะเกิดเหตุการณ์ที่ไม่สามารถควบคุมหรือไม่คาดฝันเยอะมาก ๆ ดังนั้นแต่ละ test case ต้องสามารถทำงานซ้ำ ๆ แล้วยังไม่ผลเหมือนเดิมทุกครั้ง ไม่ใช่ ทำงานผ่านบ้างไม่ผ่านบ้าง !! แบบนี้จะไม่มีใครเชื่อถือการทดสอบเลย สุดท้ายก็จะเลิกใช้ เลิกทำและกลับไปทำแบบเดิมก่อนหน้านี้ !! อะไรก็ตามที่ไม่สามารถควบคุมได้ เราต้องหัดเรียนรู้การควบคุม เนื่องจากมันจะทำให้เรามีปัญหาได้ ยกตัวอย่างเช่น เรื่องของเวลา และ Timezone เป็นต้น

โครงสร้างของชุดการทดสอบต้องดีด้วย

เริ่มตั้งแต่ชื่อของ test case ต้องสื่อถึงสิ่งที่ต้องการจะทดสอบ ทั้ง input และ expected result ชื่อยาวไม่ต้องกลัวเรื่องของ performance ว่าจะช้า เนื่องจากมันอยู่ในส่วนของการทดสอบ ไม่ใช่ระบบงานจริงนะ โครงสร้างหลัก ๆ ของแต่ละ test case ควรประกอบไปด้วย การกำหนดหรือจัดการค่าเริ่มต้นที่ต้องการ การกระทำที่ต้องการทดสอบ ตรวจสอบผลการทำงานว่าเป็นไปตามที่คาดหวังหรือไม่ ในส่วนสุดท้าย จะสำคัญมาก ๆ สำหรับการทดสอบ ถ้าไม่มีก็อย่าเขียนมาดีกว่านะ เมื่อกำหนดโครงสร้างที่ดีแล้ว ต้องใช้ให้เหมือนกันด้วย เพื่อง่ายต่อการทำงานเป็นทีม อย่าลืมว่าชุดการทดสอบ มันคือเอกสารชนิดหนึ่ง เพื่อใช้อธิบายการทำงานภายในของระบบ ทั้ง class และ function ต่าง ๆ เพื่อให้คนอื่น ๆ เข้ามาอ่านอีกด้วย ดังนั้นทำให้ดี ๆ นะ

โดยสิ่งที่จะเน้นมาก ๆ คือ การคิดก่อนทำ (TDD)

นั่นคือ ก่อนที่จะเริ่มต้นทำ คุณต้องเข้าใจปัญหา หรือ มีเป้าหมายก่อน จากนั้นจึงแบ่งปัญหาใหญ่ออกเป็นปัญหาย่อย เพื่อให้แก้ไขปัญหาได้ง่ายขึ้น ค่อยทำไป test case by test case

ยังมีเรื่องของ Test Double อีก

ทั้ง Dummy, Stub, Spy, Mock และ Fake ซึ่งล้วนมีเป้าหมายที่ต่างกันไป แต่เป้าหมายที่เหมือนกันคือ ทำการควบคุมสิ่งที่ควบคุมไม่ได้ เพื่อให้เราสามารถเขียน test case ได้ดีขึ้น ยกตัวอย่างเช่น ถ้าต้องการทดสอบ buisiness flow ที่ต้องไปดึงข้อมูลจาก API และ Database คำถามคือ เราจะควบคุม API และ Database อย่างไร ? เพื่อให้เราสามารถทดสอบ business flow ได้ครบทุกเงื่อนไข ทั้ง success และ fail case คำตอบคือ ยากมาก ดังนั้นเราลองมาใช้แนวคิดของ Test Double มาช่วย

การทดสอบจะง่ายหรือไม่นั้น

สิ่งที่สำคัญมาก ๆ คือโครงสร้างของ code ที่เราพัฒนานั้น ได้คิดหรือวางแผนว่า จะทดสอบกันอย่างไรหรือไม่ ? ถ้าไม่ได้คิดถึงการทดสอบตั้งแต่แรก การทดสอบมันยากมาก ๆ ดังนั้นโครงสร้างที่ดีก็มีชัยไปกว่าครึ่ง แต่โครงสร้างที่ดีคือ สามารถเปลี่ยนแปลงได้ตลอดเวลา ไม่ใช่ต้องใช้แบบเดิมตลอดไป เรื่องนี้สำคัญมาก ๆ มิเช่นนั้นเราจะแก้ไขปัญหาง่ายด้วยวิธีการยาก ก็เป็นไปได้ ต้องระวังให้มาก ๆ

มีคำถามว่า จะทดสอบระบบเดิมหรือ Legacy อย่างไร ?

ตอบง่าย ๆ คือ ถ้ายังไม่เข้าใจมันก็อย่าไปยุ่ง ตอบแบบนี้ อย่าตอบดีกว่า แต่สิ่งที่ควรเข้าใจคือ ของเดิมอย่าให้เพิ่ม นั่นหมายความว่า ถ้ามีการเพิ่มหรือแก้ไข ก็ให้เพิ่มชุดการทดสอบเข้าไป แน่นอนว่ามีปัญหาแน่ ๆ ดังนั้นเตรียมรับมือไว้เลย แต่จำเป็นต้องลงมือแก้ไขให้ดีขึ้น ยิ่งถ้ามี incident หรือ bug มาจาก production แล้วยิ่งดี ก็ให้เขียน test case เพื่อให้เกิดปัญหาจริง ๆ จากนั้นจึงลงมือแก้ไข ไปจนกว่า test case จะผ่าน ทำให้เราได้ test case มาแล้วนะ มันคือแนวทางของ Bug-Driven Development นั่นเอง ค่อย ๆ เพิ่มความเชื่อมั่นขึ้นไปเรื่อย ๆ เจ็บได้ แต่อย่าเจ็บซ้ำที่เดิม

บางคนบอกว่า เขียนชุดการทดสอบที่แย่ ก็อย่าเขียนเลยดีกว่า

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

วันนี้เราเขียนชุดการทดสอบกันหรือยัง ? ถ้ายัง ไปเขียนได้แล้ว Shut up and write test