Mock API แบบรวดเร็วด้วย Postman

Mock API คืออะไร ทำไมเราต้องทำด้วย?

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

จากรูปนี้ครับ

https://martinfowler.com/articles/practical-test-pyramid.html

ให้ลองนึกภาพว่าโปรแกรมของเราประกอบด้วยกล่องลูกบาสก์เล็ก ๆ หลายกล่อง ที่มีการเชื่อมต่อกันกับลูกบาสก์กล่องอื่น ๆ สิ่งที่เราค้องทำให้ได้คือการยกเอากล่องลูกบาสก์ที่ต้องการทดสอบนี้ขึ้นมาแล้วทำการทดสอบโดยเราต้องสามารถควบคุมสิ่งรอบตัวได้ทั้งหมด ซึ่งเทคนิคนี้มีชื่อว่าการทำ Test double (มันคือการล้อเลียนคำจากคำว่า Stunt double ซึ่งคือสตั๊นท์แมนที่ทุกคนน่าจะเคยเห็นในภาพยนตร์ครับ)

Test Double is a generic term for any case where you replace a production object for testing purposes

ซึ่งใน Family ของการทำ Test double นั้นก็มีอยู่หลากหลายรูปแบบด้วยกันครับ สามารถศึกษาเพิ่มเติมได้ที่ลิงค์ด้านล่าง

bliki: TestDouble

ซึ่งคำว่า Mock ก็คือหนึ่งใน family ของการทำ Test double นั่นเอง ซึ่งเอาจริง ๆ มันก็มีปลีกย่อยของมันอีกว่ามันต่างกับประเภทอื่นอย่างไร แต่ปัจจุบันส่วนใหญ่เวลาพูดกันถึงการทดสอบและต้องการตัด Dependency ที่ไม่เกี่ยวข้องเค้าก็เหมารวมกันว่า Mock นั่นเอง

สำหรับรายละเอียดหากสนใจก็ศึกษาต่อได้จากลิงค์ที่พี่ปุ๋ยเขียนไว้ที่ค่อนข้างกระชับและครบถ้วยครับ

มาดูกันว่า Mock, Stub และ Dummy แตกต่างกันอย่างไร ?

กลับมาสู่โลกของการพัฒนาแอพพลิเคชั่นในปัจจุบันกันครับ ปกติเรามักจะพัฒนาโดยแยกส่วนของ Front-end และ Backend กันชัดเจน เพื่อให้ง่ายต่อการพัฒนา และ การดูแลรักษาตัว Source code เนื่องจากช่วงหลายปีก่อนเรายังไม่เคยทำแบบนี้จึงเกิดปัญหาที่หลายที่มักเจอนั่นก็คือการที่ Front-end กับ Logic backend พันกันจนยุ่งเหยิง

https://samnewman.io/patterns/architectural/bff/

แน่นอนทุกแนวทางใหม่มันจะมักนำพาปัญหาใหม่ ๆ มาด้วย เช่น เรามักลืมตกลงกันในเรื่องของหน้าตา Backend API จนทำให้เกิดปัญหาการพัฒนาไปคนละทิศคนทาง ไม่ได้สนใจสิ่งที่จะออกมาร่วมกัน หรือ การไม่มี Document ของหน้าตา API ที่เราออกแบบ

แต่ปัญหานึงที่เรามักจะเจอเมื่อแบ่งแบบนี้คือการทำงานฝั่ง Front-end ต้องรอให้ Backend เสร็จก่อน เพราะ ยังเชื่อมต่อ API (หลังจากนี้ผมจะเรียก Backend ว่า API ครับ) ไม่ได้ ทำให้ระยะเวลาการพัฒนามันไม่สามารถจบได้เป็นรอบได้ บ้างก็แก้ด้วยการให้ API ทำนำหน้าไปก่อนเลย ส่วน Front-end ค่อยตามมา แต่ปัญหาก็เกิดอีกนั่นก็คือเจ้า API เจ้ากรรมที่เราเคยออกแบบกันไว้ พอมาประกอบกันฝั่ง Front-end ดันไม่ครบ หรือไม่ก็ไม่ตรงกับที่ลูกค้าอยากให้เป็น มหกรรมงานช้างก็เกิดอีกครั้งนั่นก็คือการที่ทีม API ก็ต้องกลับมาแก้ใหม่ ความลำบากของทุกครั้งที่ส่งงานให้กับลูกค้าก็จะเกิดปัญหาประมาณว่าฝั่ง API ทำผิด ส่วนฝั่งทีมที่ทำ API ก็อ้างว่าฝั่ง Front-end เรียกใช้งานไม่ถูก หรือ บอกข้อมูลที่อยากได้มาไม่ครบ

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

ถูกต้อง… เราก็ Mock มันไปเลย ให้มองว่าการจะตัด Dependency ระหว่าง Front-end กับ Backend ก็เพียงแค่สร้างตัวปลอมขึ้นมาให้ใช้งานไปก่อนโดยยังไม่ต้องทำออกมาจริง

• ฝั่ง Front-end ก็ Happy ได้ข้อมูลลองไปเรียกใช้งาน
• ฝั่ง API ก็ Happy ได้ตัวอย่างของหน้าตา API ที่จะพัฒนาแบบจับต้องได้

แล้วเราจะใช้อะไรในการ Mock API ดีล่ะ?

เอาจริง ๆ ทางเลือกมันมีหลายทางมาก ปัญหาที่เราเจอมันไม่ใช่เรื่องใหม่เลย จากที่เห็นนิยมใช้กันก็มี

• json-server ตัวช่วยในการสร้าง API แบบ mock ขึ้นมาโดยใช้แค่การตั้งค่าต่าง ๆ ผ่านไฟล์ JSON

Create A REST API With JSON Server

• swagger.io ตัวสร้าง API Document ยอดนิยมที่เราสามารถสร้าง Mock API ได้จากค่าต่าง ๆ ที่เรากำหนดไว้
• Postman ใช่แล้วมันก็สามารถทำ Mock API ได้ เนื่องด้วยทีมของเราตอนนี้ใช้การวางแผนไปจนถึงขั้นตอนการทดสอบด้วย Postman อยู่แล้ว ดังนั้นในขั้นตอนการพัฒนานอกจากจะทำเป็น Document ในทีมเราก็จะทำให้มันเกิดเป็น API แบบ Mock ๆ ขึ้นมาซ่ะเลย

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

ขั้นตอนการสร้าง Mock API ด้วย Postman

1. สร้าง Collection ขึ้นมาก่อนครับ (ก่อนหน้าให้ทำการติดตั้ง Postman และลงทะเบียนให้เรียบร้อยเพื่อให้สามารถใช้งานฟีเจอร์เสริมเหล่านี้ได้)

2. ทำการสร้าง Request เพิ่มขึ้นมา (Add request)

3. ใส่ API Url ว่า

{{url}}/users/{{id}}

สามารถศึกษาการใช้งานเรื่อง Environment variable ได้ที่นี่

4. จากนั้นให้ทำการเพิ่ม Example ของ API นี้ขึ้นมา (ตัวนี้แหละครับ ที่จะทำให้เราสามารถกำหนดหน้าตาของ API ที่ต้องการ Mock ได้)

5. ให้ทำการแก้ไขตรง URL ที่ต้องการให้เป็นตัวอย่าง และ Example response

จากตัวอย่างในรูป ผมจะสร้างตัวอย่างของการเรียกใช้งาน /users/1 และแสดงข้อมูลของผู้ใช้งานคนนี้ออกมาในหน้าตาแบบนี้

6. เมื่อเราได้กำหนดค่าทั้งหมดแล้วก็ถึงเวลาที่เราจะสร้าง Mock server ขึ้นมาจากค่าต่าง ๆ ที่เราได้ตั้งค่าไปครับ

กดที่ปุ่ม … หลัง Collection ของเราเอง จากนั้นให้เลือก Mock collection ครับ

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

จากนั้นทำการสร้างโดยการกดที่ “Create”

เราก็จะพบว่าทาง Postman ได้สร้าง Public endpoint API ขึ้นมาดังรูป

7. เมื่อทดลองเรียกใช้งานผ่าน Mock API นี้เราก็จะได้แบบนี้

ซึ่งค่าที่แสดงก็จะ Match ตามที่เรากรอกไว้ ซึ่งหลักการในการค้นหามันไม่ใช่แค่ URL ที่เรากรอกแต่รวมถึง Param หรือ Body ที่ต้องการด้วย ดังนั้นทำให้เราสามารถทดสอบได้หลากหลาย ยืดหยุ่นตามที่เราออกแบบ API ไว้เลยทีเดียว

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

ใช้แล้วดีไหม?

จุดที่ยังเป็นจุดด้อยคือ มันเหมาะกับทีมเล็ก ๆ เนื่องจากราคาค่อนข้างสูงพอสมควร ซึ่งถ้าเราใช้งานแบบฟรี การใช้งานของ Mock API จะเรียกใช้งานได้เพียง 1000 request / เดือน ซึ่งนับว่าน้อยอย่างยิ่ง แต่ด้วยตอนนี้เรายังตอบโจทย์กับการใช้เครื่องมือนี้และวิธีการทำงานในรูปแบบนี้ ในอนาคตทีมเราก็อาจจะต้องเปลี่ยนไปเครื่องมืออื่น ๆ เพื่อให้ตอบโจทย์กับปัญหาที่เราเจอมากท่ีสุด

Reference

How to reduce development time? Mock your APIs

Setting up a mock server | Postman Learning Center