หากคุณเขียนการทดสอบฝั่งฟรอนต์เอนด์ คุณอาจเคยใช้ Mock Service Worker (MSW) เป็นไลบรารีที่นิยมใช้สำหรับการดักจับคำขอภายในเบราว์เซอร์และ Node และสำหรับการทดสอบยูนิตและคอมโพเนนต์ก็ยากที่จะหาตัวจับยาก คู่มือนี้จะอธิบายว่า MSW ทำอะไรได้ดี, จุดที่ประสิทธิภาพเริ่มลดลง, และเมื่อใดที่ แพลตฟอร์มจำลอง API แบบโฮสต์จะเหมาะสมกว่า
button
Mock Service Worker คืออะไร?
Mock Service Worker เป็นไลบรารี JavaScript ที่ดักจับคำขอเครือข่ายที่ต้นทาง ในเบราว์เซอร์ จะลงทะเบียน Service Worker ที่จะจับการเรียก `fetch` และ `XMLHttpRequest` ที่ส่งออกไป ใน Node จะแก้ไขเลเยอร์คำขอเพื่อให้แฮนเดลอร์เดียวกันนี้ทำงานใน Jest หรือ Vitest คุณจะเขียนแฮนเดลอร์คำขอที่ตรงกับเมธอดและพาธ จากนั้นส่งกลับการตอบสนองที่คุณต้องการ
การออกแบบนี้ชาญฉลาด โค้ดแอปพลิเคชันของคุณยังคงเรียกใช้ API เครือข่ายจริง MSW จะอยู่ตรงกลางและตอบกลับ ดังนั้นคุณไม่จำเป็นต้องสตับ `fetch` หรือสลับไคลเอนต์ HTTP ของคุณ คำจำลองเดียวกันนี้ใช้ได้ทั้งในการทดสอบและในบิลด์สำหรับนักพัฒนาที่กำลังรันอยู่ นี่คือเหตุผลที่ทีม React และ Vue จำนวนมากเลือกใช้มัน คุณสามารถเจาะลึก ซอร์สโค้ดของ MSW บน GitHub เพื่อดูว่าเลเยอร์การดักจับทำงานอย่างไร
แฮนเดลอร์ทั่วไปมีลักษณะดังนี้:
import { http, HttpResponse } from 'msw'
export const handlers = [
http.get('/api/users/:id', ({ params }) => {
return HttpResponse.json({ id: params.id, name: 'Ada Lovelace' })
}),
]
นั่นคือเสน่ห์ทั้งหมดของมัน ม็อกจะอยู่ถัดจากโค้ดของคุณ มีการควบคุมเวอร์ชันพร้อมกับการทดสอบของคุณ และทำงานได้ทุกที่ที่ JavaScript ของคุณทำงาน
MSW โดดเด่นในด้านใด
MSW เหมาะสมอย่างยิ่งเมื่อม็อกและตัวใช้งานอยู่ในโค้ดเบสเดียวกัน นี่คือบางกรณีที่มันเป็นเครื่องมือที่เหมาะสมอย่างแท้จริง:
- การทดสอบคอมโพเนนต์และยูนิต เรนเดอร์คอมโพเนนต์ ให้มันยิงคำขอจริง และส่งกลับข้อมูลที่เตรียมไว้ ไม่ต้องมี Test Doubles เพื่อเชื่อมต่อ หากคุณกำลังเปรียบเทียบกับการสอดแนมไคลเอนต์โดยตรง ให้ดูว่าสิ่งนี้แตกต่างจาก Jest mock ของการเรียก API อย่างไร
- การพัฒนาฟรอนต์เอนด์ในเครื่อง สร้าง UI ก่อนที่แบ็คเอนด์จะถูกสร้างขึ้น สลับแฮนเดลอร์เพื่อจำลองการโหลด ข้อผิดพลาด หรือสถานะว่างเปล่าตามต้องการ
- CI ที่คาดการณ์ผลลัพธ์ได้ การทดสอบไม่แตะต้องเซิร์ฟเวอร์จริง ดังนั้นจึงไม่มีปัญหาเรื่องเงื่อนไขเครือข่ายหรือข้อมูล staging ที่ใช้ร่วมกัน
- หนึ่งภาษา หนึ่งทีม เมื่อผู้ที่เขียนม็อกคือผู้ที่ใช้งาน การเก็บแฮนเดลอร์ไว้ใน repo เป็นวิธีที่ง่ายที่สุด
หากสถานการณ์ของคุณเป็นไปตามที่กล่าวมานี้ คุณอาจไม่จำเป็นต้องใช้อะไรอื่นอีก MSW นั้นฟรี เป็นโอเพนซอร์ส และสร้างขึ้นมาเพื่อสิ่งนี้โดยเฉพาะ
เมื่อ MSW เริ่มทำงานหนัก
สิ่งเดียวกันที่ทำให้ MSW ยอดเยี่ยมใน repo เดียวกัน นั่นคือม็อกที่อยู่ในโค้ดใน repo นั้น คือสิ่งที่จำกัดมันเมื่อมีคนเข้ามาเกี่ยวข้องมากขึ้น นี่คือจุดที่ทีมมักจะเติบโตเกินกว่ามัน
ผู้ใช้งานที่ไม่ใช่ JavaScript
แฮนเดลอร์ของ MSW เป็น JavaScript หากทีมโมบายของคุณเขียน Swift หรือ Kotlin หรือการทดสอบการรวมระบบแบ็คเอนด์ของคุณทำงานใน Go หรือ Python พวกเขาไม่สามารถนำเข้าแฮนเดลอร์ของคุณได้ พวกเขาจะต้องสร้างม็อกของตัวเอง ซึ่งจะแตกต่างจากของคุณ เซิร์ฟเวอร์จำลอง ที่ไม่ขึ้นกับภาษาที่สื่อสารผ่าน HTTP บน URL จริงจะทำงานได้กับไคลเอนต์ทุกประเภท ไม่ว่าจะใช้ภาษาใดก็ตาม
ม็อกที่ใช้ร่วมกันและเปิดตลอดเวลา
MSW ทำงานภายในกระบวนการ ไม่มี URL ที่ใช้ร่วมกันที่วิศวกร QA นักออกแบบ หรือทีมพันธมิตรสามารถเข้าถึงได้จากเครื่องของตนเอง ทันทีที่คุณต้องการปลายทางเดียวที่หลายคนใช้พร้อมกัน คุณต้องมีเซิร์ฟเวอร์จำลองแบบโฮสต์ที่มีที่อยู่คงที่ ไม่ใช่ Service Worker ที่ผูกติดอยู่กับแท็บเบราว์เซอร์เดียว
เวิร์กโฟลว์ที่เน้นการออกแบบเป็นหลักและขับเคลื่อนด้วย Schema
หากคุณออกแบบ API ใน OpenAPI ก่อนที่จะเขียนโค้ด คุณต้องการม็อกที่สร้างขึ้นจากสเปกโดยอัตโนมัติ เพื่อให้ม็อกไม่ขัดแย้งกับสัญญา MSW คาดหวังให้คุณเขียนแฮนเดลอร์ด้วยตนเอง การสร้างม็อกโดยตรงจาก Schema เป็นโมเดลที่แตกต่างกัน คุณสามารถอ่านเพิ่มเติมเกี่ยวกับแนวทางนี้ได้ในคู่มือนี้เกี่ยวกับ การจำลอง API และรูปแบบที่เกี่ยวข้อง
ข้อมูลไดนามิกที่สมจริงในปริมาณมาก
MSW จะส่งคืนสิ่งที่โค้ดแฮนเดลอร์ของคุณเขียน สำหรับข้อมูลที่สมจริงในหลายฟิลด์ คุณจะต้องเขียนลอจิกนั้นด้วยตนเอง แพลตฟอร์มที่เชื่อมต่อการสร้างข้อมูลสไตล์ faker และการอนุมานชื่อฟิลด์จะให้การตอบสนองที่สมจริงโดยไม่ต้องสร้างขึ้นด้วยตนเองทีละรายการ
MSW เทียบกับแพลตฟอร์มจำลอง API เต็มรูปแบบ
นี่คือการเปรียบเทียบแบบตรงไปตรงมา ไม่มีคอลัมน์ใดที่ "ดีกว่า" ในเชิงนามธรรม พวกมันแก้ปัญหาที่แตกต่างกัน
| ความสามารถ | Mock Service Worker | แพลตฟอร์ม API แบบโฮสต์ (เช่น Apidog) |
|---|---|---|
| รันภายใน JS unit/component tests | ใช่, เป็นแบบ native | ไม่, ไม่ใช่ไลบรารีการทดสอบ JS |
| ไม่ขึ้นกับภาษาผ่าน HTTP | ไม่ (เฉพาะ JS) | ใช่, ไคลเอนต์ใดก็ได้ |
| URL ที่ใช้ร่วมกันสำหรับทั้งทีม | ไม่ | ใช่, เซิร์ฟเวอร์จำลองแบบโฮสต์ |
| สร้างม็อกจาก OpenAPI | ด้วยตนเอง | อัตโนมัติจาก Schema |
| การสร้างข้อมูลอัจฉริยะ/ไดนามิก | เขียนโค้ดด้วยตนเอง | มีมาให้ในตัว |
| อยู่ใน repo ของคุณพร้อมกับการทดสอบ | ใช่ | เก็บในโปรเจกต์ที่ใช้ร่วมกัน |
| ค่าใช้จ่าย | ฟรี, โอเพนซอร์ส | แบบฟรี + แผนแบบชำระเงิน |
ข้อสรุป: MSW เป็นทางเลือกที่เหมาะสมสำหรับการทดสอบฟรอนต์เอนด์และการพัฒนาในเครื่อง แพลตฟอร์มอย่าง Apidog เป็นทางเลือกที่เหมาะสมเมื่อม็อกต้องมีการแชร์, เป็นกลางทางภาษา, หรือขับเคลื่อนด้วยสเปก
Apidog เป็นส่วนเสริม ไม่ใช่สิ่งทดแทน
เพื่อให้ชัดเจน Apidog ไม่ใช่สิ่งทดแทนสำหรับ MSW ใน Jest หรือ Vitest ไม่ใช่ไลบรารี JavaScript ที่คุณนำเข้าไฟล์ทดสอบ ถือว่ามันเป็นเลเยอร์ที่อยู่เหนือการทดสอบยูนิตของคุณ เป็นที่ที่ม็อกกลายเป็นทรัพยากรที่ใช้ร่วมกันและไม่ขึ้นกับภาษาสำหรับทั้งทีม
นี่คือสิ่งที่ดูเหมือนในทางปฏิบัติ คุณออกแบบหรือนำเข้า API ใน Apidog และมันจะสร้างปลายทางจำลองโดยอัตโนมัติจาก Schema ม็อกจะได้รับ URL จริงที่เพื่อนร่วมทีมฟรอนต์เอนด์, โมบายล์ และ QA ของคุณสามารถเรียกใช้ได้ทั้งหมด Apidog จะเติมการตอบสนองด้วยข้อมูลที่สมจริงโดยการอนุมานจากชื่อฟิลด์ ดังนั้นฟิลด์ที่ชื่อ `email` จะส่งคืนอีเมล และ `createdAt` จะส่งคืนวันที่ คุณยังสามารถเขียนกฎที่กำหนดเองได้เมื่อคุณต้องการการตอบสนอง 500 ที่เฉพาะเจาะจง หรือกรณีขอบบางอย่าง
เนื่องจากม็อกมาจาก Schema เดียวกันกับการออกแบบและการทดสอบของคุณ จึงทำให้มันซิงค์กับสัญญาอยู่เสมอ นั่นคือส่วนที่แฮนเดลอร์ที่เขียนด้วยมือไม่สามารถรับประกันได้ หากคุณต้องการดูว่าการสร้าง Schema-to-mock เปรียบเทียบกันอย่างไรในเครื่องมือต่างๆ คู่มือ เครื่องมือจำลอง API ที่ดีที่สุด นี้จะรวบรวมตัวเลือกต่างๆ มาไว้ข้างกัน
การแบ่งแยกที่ใช้งานได้จริงที่หลายทีมเลือกใช้:
- ใช้ MSW สำหรับการทดสอบคอมโพเนนต์และยูนิตภายใน repo ฟรอนต์เอนด์
- ใช้ม็อกแบบโฮสต์สำหรับการรวมระบบข้ามทีม การสาธิต และผู้ใช้งานที่ไม่ใช่ JS
คุณไม่ได้เลือกเพียงอย่างเดียว คุณกำลังใช้แต่ละอย่างในที่ที่เหมาะสม ดาวน์โหลด Apidog หากคุณต้องการลองใช้ด้านโฮสต์ควบคู่ไปกับการตั้งค่า MSW ที่มีอยู่ของคุณ
ทางเลือกอื่นของ MSW ที่ควรรู้
MSW ไม่ใช่ไลบรารีจำลองเพียงอย่างเดียว และแพลตฟอร์มก็ไม่ใช่ทางเลือกเดียวของคุณ ขึ้นอยู่กับสแต็กของคุณ:
- Mockoon เป็นแอปเดสก์ท็อปสำหรับสร้างเซิร์ฟเวอร์จำลองในเครื่องอย่างรวดเร็ว ด้วย GUI แทนโค้ด
- WireMock เป็นเซิร์ฟเวอร์จำลองที่ใช้ Java เหมาะสำหรับทีม JVM และการทดสอบสัญญา
- Prism โดย Stoplight สร้างม็อกโดยตรงจากไฟล์ OpenAPI ผ่าน Command Line
- json-server เปลี่ยนไฟล์ JSON ให้เป็น REST API อย่างรวดเร็วสำหรับการสร้างต้นแบบ
แต่ละอย่างมีการแลกเปลี่ยนกัน WireMock และ Prism เน้นงานแบ็คเอนด์และสัญญา; Mockoon และ json-server เน้นการตั้งค่าในเครื่องอย่างรวดเร็ว หากปัญหาของคุณคือ "MSW ไม่สามารถช่วยเพื่อนร่วมทีมที่ไม่ใช่ JS ของฉันได้" เซิร์ฟเวอร์จำลองที่ใช้ HTTP ใดๆ ก็สามารถแก้ปัญหานี้ได้ สำหรับมุมมองฟรอนต์เอนด์ที่กว้างขึ้น ดูว่าทีมต่างๆ จัดการ การจำลอง API ใน React ด้วย Axios อย่างไร
คำถามที่พบบ่อย
MSW ฟรีหรือไม่?
ใช่ Mock Service Worker เป็นโอเพนซอร์สภายใต้ใบอนุญาต MIT และใช้งานได้ฟรีในทุกโปรเจกต์ ไม่ว่าจะเป็นเชิงพาณิชย์หรือไม่ก็ตาม คุณจะเริ่มจ่ายเมื่อคุณเปลี่ยนไปใช้แพลตฟอร์มแบบโฮสต์สำหรับม็อกที่ใช้ร่วมกัน และเครื่องมืออย่าง Apidog ก็มีบริการฟรีสำหรับสิ่งนั้นด้วย
Apidog สามารถแทนที่ MSW ในการทดสอบยูนิตของฉันได้หรือไม่?
ไม่ และคุณไม่ควรพยายามทำเช่นนั้น MSW ดักจับคำขอภายในตัวรันการทดสอบ JavaScript ของคุณ Apidog เป็นแพลตฟอร์มแบบโฮสต์ ไม่ใช่ไลบรารีที่สามารถนำเข้าได้ ดังนั้นจึงไม่สามารถอยู่ใน Jest หรือ Vitest ได้เหมือน MSW ใช้ Apidog สำหรับม็อกที่ใช้ร่วมกัน, ข้ามทีม, หรือขับเคลื่อนด้วย Schema แทน หากคุณมุ่งเน้นไปที่ด้านตัวรันการทดสอบเท่านั้น บทแนะนำเกี่ยวกับ วิธีการจำลองการเรียก API นี้ครอบคลุมแนวทางในการเขียนโค้ด
MSW ทำงานใน Node หรือเฉพาะในเบราว์เซอร์เท่านั้น?
ทั้งสองอย่าง ในเบราว์เซอร์ MSW ใช้ Service Worker ใน Node จะแก้ไขเลเยอร์คำขอเพื่อให้แฮนเดลอร์เดียวกันทำงานใน Jest, Vitest หรือสภาพแวดล้อมการทดสอบ Node ใดๆ โหมดคู่ขนานนี้เป็นหนึ่งในจุดแข็งที่ใหญ่ที่สุดสำหรับทีม JS ฟูลสแตก
ฉันควรเปลี่ยนจาก MSW ไปใช้เซิร์ฟเวอร์จำลองแบบโฮสต์เมื่อใด?
เปลี่ยน หรือเพิ่มเซิร์ฟเวอร์หนึ่งเมื่อม็อกจำเป็นต้องแชร์ สัญญาณที่ชัดเจนที่สุด: ไคลเอนต์ที่ไม่ใช่ JavaScript ต้องการมัน, หลายคนต้องการ URL ที่เสถียรเดียวกัน, หรือคุณออกแบบ API แบบ spec-first และต้องการม็อกที่สร้างจาก OpenAPI โดยอัตโนมัติ
สรุป
MSW ยอดเยี่ยมในสิ่งที่สร้างมาเพื่อ: การดักจับคำขอภายใน JavaScript สำหรับการทดสอบฟรอนต์เอนด์และยูนิต มันไม่ได้พยายามที่จะเป็นม็อกที่ใช้ร่วมกัน, โฮสต์, และไม่ขึ้นกับภาษา และนั่นก็ไม่ใช่ปัญหา เมื่อม็อกของคุณจำเป็นต้องออกจาก repo, เมื่อภาษาอื่นหรือทีมอื่นต้องการมัน, หรือเมื่อคุณต้องการให้มันถูกสร้างขึ้นจากสเปก นั่นคือช่วงเวลาที่จะเพิ่มแพลตฟอร์มเต็มรูปแบบควบคู่ไปกับมัน
Apidog จัดการด้านที่ใช้ร่วมกันและขับเคลื่อนด้วย Schema: เซิร์ฟเวอร์จำลองแบบโฮสต์ที่มี URL จริง, ม็อกอัตโนมัติจากการออกแบบ OpenAPI ของคุณ, และข้อมูลที่สมจริงตั้งแต่เริ่มต้น ให้ MSW ทำงานในจุดที่แข็งแกร่ง และให้ Apidog ดูแลทุกอย่างที่อยู่นอกเหนือขอบเขตของตัวรันการทดสอบของคุณ ดาวน์โหลด Apidog และชี้ฟรอนต์เอนด์ของคุณไปยังม็อกที่ใช้ร่วมกันเพื่อดูความแตกต่าง
button