Screen Shot 2558-02-22 at 3.26.42 PM
วันนี้ทำการ run test ที่อยู่จำนวนเยอะๆ แล้วพบว่า
มันเริ่มใช้เวลานานขึ้นเรื่อยๆ
ถึงแม้ว่าจะให้ทำการทดสอบแบบ parallel แล้วก็ตาม

จึงมีแนวคิดว่า
ทำไมที่เครื่องเรามันต้อง run test ทุกตัวด้วยนะ ?
เพราะว่าไม่อยากรอนานๆ
จะได้เอาเวลาไปทำอย่างอื่นที่มีประโยชน์กว่า !!

จากการดู code ที่เปลี่ยนแปลง และ test ทั้งหมดพบว่า
code ที่เราเปลี่ยนแปลงนั้น มันกระทบหรือมี test ที่เกี่ยวข้องน้อยมาก
หรือพูดได้ว่า 99% ของ test ที่เราทำการทดสอบ
ไม่ได้เกี่ยวข้องกับ code ที่เราทำแก้ไขเลยนะ

ดังนั้น ทำไมเราต้องมาเสียเวลา run test เหล่านั้นด้วยล่ะ ?

เริ่มต้นด้วยการค้นหา

พบ 2 เรื่องที่น่าสนใจคือ

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

ถ้าทำการทดสอบผ่านแล้ว จึงให้ทำการ push code ขึ้น repository
เพื่อให้ระบบ Continuous Integration ทำการ run test ให้ครบทั้งหมดอีกรอบ

ดังนั้น ถ้ามีแนวทางที่แจ่มๆ สำหรับลดเวลาการทดสอบลงไปได้สักครึ่งหนึ่ง
มันน่าจะดีไหมนะ ? …

จากบทความ Predicting Test Failures อธิบายไว้ว่า

ในการเลือกชุดของการทดสอบ ที่เกี่ยวข้องกับ code ที่ทำการเปลี่ยนแปลงนั้น
เป็นกระบวนการที่เรียกว่า Regression Test Selection
โดยจะทำการตอบปัญหานี้

ถ้าทำการแก้ไข code บรรทัดที่ A ของไฟล์ B
แล้วควรจะทำการ run test อะไรบ้าง ?

โดยตัวอย่างใช้สำหรับ Minitest และ RSpec มีขั้นตอนดังนี้

  • ต้องทำการเก็บ code coverage ของแต่ละ test ไว้
  • ดูว่ามี code ส่วนไหนถูกแก้ไขบ้าง ( git diff นั่นเอง ) จะได้ชื่อ file บรรทัด และ method ที่ทำการแก้ไข
  • ทำการจับคู่ระหว่าง code ที่แก้ไข กับชุดการ test ทำให้เรารู้ว่าจะต้อง run test อะไรบ้าง

ถ้าสนใจ code เชิญอ่านได้ที่นี่ Github::MyThing
ซึ่งเป็นแนวทางที่น่าสนใจมาก
แต่ก็ต้องใช้ความรู้และความเข้าใจเยอะหน่อย

โดยที่ทางผู้เขียน blog เรื่อง Predicting Test Failure ได้บอกไว้ว่า

แนวคิดเรื่อง failure prediction และ regression test selection
มันจะเป็นแนวคิด และ เครื่องมือที่ดีมาก สำหรับการจัดการกับ Legacy code
และที่สำคัญคือ มันทำให้คุณทดสอบได้อย่างรวดเร็วกว่าเดิมนะ
อีกเรื่องที่สำคัญก็คือ ยิ่งนานไปข้อมูลของ code coverage จะเยอะขึ้นเรื่อยๆ
ดังนั้น ต้องมีตัวมาจัดการ เพื่อให้การค้นหา และ การจับคู่รวดเร็วยิ่งขึ้น

พอลงไปดูรายละเอียดที่ได้จาก Code coverage ของ Cubertura แล้ว

จึงเข้าใจว่าไม่มีอะไรในกอไผ่เลย
เนื่องจากใน report มันบอกหมดเลยว่าผลของ code coverage เป็นอย่างไร
ดังรูป

Screen Shot 2558-02-22 at 3.21.44 PM

ดังนั้น เราสามารถนำข้อมูลเหล่านี้
ไปจับคู่กับ code ที่เปลี่ยนแปลงได้
ทำให้เรารู้ว่าควรจะเลือก test ใดมาทดสอบบ้างนั่นเอง
ดังนั้นเราลงมือสร้างระบบนี้ขึ้นมาดีกว่า …