มีโอกาสแบ่งปันเรื่องการทดสอบระบบงานแบบอัตโมมัติ (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