นั่งอ่าน Slide ของคุณ Martin Fowler เกี่ยวกับการทดสอบใน Microservice
ซึ่ง slide ได้อธิบายการทดสอบในทุกๆ ระดับ ตั้งแต่

  • Unit testing
  • Integration testing
  • Component testing
  • End-to-end testing
  • Exploratory testing

และมีการพูดถึงการทดสอบอีกอย่างคือ Contract testing ซึ่งน่าสนใจมาก
ซึ่งผมไม่เคยได้ยินมาเหมือนกัน ดังนั้นมาศึกษากันดีกว่า
รูป pyramid testing
Screen Shot 2557-12-02 at 7.53.26 PM

โดยปกติเราจะทำการทดสอบในระดับ unit, integration และ component กันอยู่แล้ว
การทดสอบเหล่านี้สามารถครอบคลุมระบบในระดับที่สูงได้ไม่ยาก (High coverage)
แต่สิ่งหนึ่งที่ การทดสอบอาจจะยังไม่ครอบคลุม
นั่นคือ external dependency หรือระบบภายนอก
เราจะมั่นใจได้อย่างไรว่า  ระบบของเรายังคงทำงานกับระบบภายนอกได้อยู่นะ ?
ซึ่งรูปแบบการทดสอบนี้จะเรียกว่า Contract testing

Contract testing คือ

การทดสอบที่กรอบของระบบภายนอก หรือ external service
เพื่อทำการตรวจสอบ และ ทำให้มั่นใจว่า ส่วนที่เชื่อมต่อกันมันยังทำงานด้วยกันได้นะ
Screen Shot 2557-12-03 at 10.12.58 AM

โดยในส่วนเชื่อมต่อกันนั้น จะประกอบไปด้วยสิ่งที่คาดหวังคือ

  • Input
  • Output
  • ผลกระทบต่างๆ
  • ประสิทธิภาพในการทำงาน
  • ลักษณะของ concurrency


จะสังเกตได้ว่า ผู้ใช้งาน (Consumer) ส่วนการติดต่อหนึ่งๆ นั้น สามารถมีได้เยอะ
และผู้ใช้งานแต่ละคน หรือ แต่ละ component ก็อาจจะใช้งานผ่านส่วนการติดต่อเดียวกัน
แต่มี input และ output ที่แตกต่างกันตาม requirement
รวมทั้งถ้าส่วนการติดต่อนี้อาจจะต้องเปลี่ยนแปลงอยู่ตลอดเวลา
แล้วเราจะมั่นใจได้อย่างไรว่า ผู้ใช้งานอื่นๆ
ยังสามารถใช้งานส่วนการติดต่อนั้นๆ ได้อยู่นะ ?

โดยที่การทดสอบแบบนี้มันไม่ใช่ Component testing
เนื่องจากมันไม่ได้ทดสอบพฤติกรรมภายในของ service หรือ component
เพียงแต่สนใจที่ input และ output เท่านั้น ว่ายังสามารถทำงานได้ตามที่คาดหวัง
รวมทั้งเรื่องของ performance เช่น latency และ throughput ยังอยู่ในขอบเขตที่ตกลงกันไว้

รูปแสดงของ Component testing
Screen Shot 2557-12-03 at 10.20.00 AM

ในการสร้าง contract testing นั้น ควรจะสร้างตามแต่ละผู้ใช้งาน

และทำการรวม และ ทำงาน ผ่าน build pipeline ในระบบ Continuous Integration ไปเลย
ซึ่งมันจะช่วยให้ผู้ดูแล service หรือ ระบบภายนอก รู้ได้ทันทีว่า
สิ่งที่เปลี่ยนแปลงใน service นั้นมันกระทบต่อผู้ใช้งานหรือไม่ อย่างไร ?

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

ถ้าคุณไม่สามารถตอบคำถามเหล่านี้ ได้
แสดงว่า คุณกำลังเจอปัญหา อยู่แล้วล่ะนะ !!!

ดังนั้น สิ่งที่คุณควรต้องทำคือ

ต้องรู้ว่าผู้ใช้งานของ service ของคุณมีส่วนไหนบ้าง
แล้วทำการรวบรวมมาเขียน contract testing ซะ
เพื่อทำให้ผู้ใช้งานมีความมั่นใจใน service ที่ใช้งาน …

และการรวบรวมผู้ใช้งานนี้ ก็จะช่วยให้ผู้ดูแล service
มีความสบายใจในการแก้ไข และ พัฒนามากขึ้น

แนวทางการทดสอบแบบนี้มัน win-win กันทุกฝ่ายเลยนะครับ
คุณทำการทดสอบแบบ contract testing แล้วหรือยัง ?

ตัวอย่างจาก slide

Service ตัวอย่าง มีข้อมูลที่ส่งออกมา 3 ตัวคือ id, name และ age
และมีผู้ใช้งาน service จำนวน 3 ที่ โดยแต่ละที่ มีรูปแบบการใช้งานที่แตกต่างกันดังนี้

  • ผู้ใช้งาน A จะใช้งานข้อมูล id และ name เท่านั้น ดังนั้นจึงไม่ทำการตรวจสอบ age
  • ผู้ใช้งาน B จะใช้งานข้อมูล id และ age เท่านั้น ดังนั้นจึงไม่ทำการตรวจสอบ name
  • ผู้ใช้งาน C จะใช้ข้อมูลทั้งหมด

แสดงดังรูป
Screen Shot 2557-12-03 at 10.37.16 AM

ถ้ามีผู้ใช้งานใหม่ ต้องการใช้งาน service โดยที่ service ต้องส่งข้อมูล
first name และ last name กลับมาให้นะ
ดังนั้น ผู้ดูแล service จำเป้นจะต้องแก้ไข service นะสิ
ซึ่งผู้ดูแล service สามารถเลือกแก้ไขได้หลายรูปแบบ

ตัวอย่างเช่น
ถ้าเลือกการยกเลิกข้อมูล name ไป
แล้วทำการสร้าง first name และ last name เข้ามาแทน

ผลที่ตามมาคืออะไร ?
นั่นมันจะส่งผลต่อผู้ใช้งาน A และ C ใช่ไหม ?
เนื่องจากในชุดการทดสอบ contract testing ทำการตรวจสอบเอาไว้..

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

รูปแบบการแก้ไขนี้ เรียกว่า Parallel Change
ซึ่งจะไม่ทำให้ระบบของผู้ใช้งานและ service ต้องสะดุด หรือ หยุดการทำงาน
เพราะว่าเกิดการเปลี่ยนแปลงขึ้น

ลองกลับไปดูระบบของคุณ ว่ามีปัญหาเรื่องเหล่านี้ไหมครับ ?

ดังนั้น น่าจะพอทำให้เห็นว่า contract testing นั้นมันมีคุณค่าอย่างไร
ทั้งผู้ดูแล และ ใช้งาน service

เครื่องมือที่แนะนำสำหรับการเขียน Contract testing มีดังนี้


วันนี้คุณทำ Contract testing แล้วหรือยัง ?
ถ้ายัง แสดงว่า ถึงเวลาต้องทำแล้วนะครับ ..

สังเกตไหมว่า ต้องทำงานร่วมกันทั้งฝั่งผู้ใช้งาน และ ผู้ดูแล service นะครับ