บทนำ: ยุทธศาสตร์การทดสอบสำหรับ tRPC ในโลก TypeScript
ในยุคที่การพัฒนาเว็บแอปพลิเคชันด้วย TypeScript กำลังเป็นที่นิยมสูงสุด tRPC (TypeScript Remote Procedure Call) ได้กลายเป็นเครื่องมือสำคัญที่ช่วยให้นักพัฒนาสามารถสร้าง API ที่ type-safe ได้อย่างง่ายดาย โดยไม่ต้องประกาศ schema ซ้ำซ้อนระหว่าง frontend และ backend อย่างไรก็ตาม ความท้าทายที่สำคัญคือการสร้างกลยุทธ์การทดสอบ (Testing Strategy) ที่มีประสิทธิภาพสำหรับ tRPC ซึ่งมีความแตกต่างจาก REST API หรือ GraphQL อย่างมีนัยสำคัญ
บทความนี้จะพาคุณดำดิ่งสู่โลกของการทดสอบ tRPC อย่างละเอียด ครอบคลุมตั้งแต่แนวคิดพื้นฐานไปจนถึงเทคนิคขั้นสูง พร้อมตัวอย่างโค้ดที่ใช้งานได้จริง ทั้งหมดนี้เขียนขึ้นสำหรับนักพัฒนา TypeScript ที่ต้องการยกระดับคุณภาพของแอปพลิเคชันของตนในปี 2026
1. ทำความเข้าใจธรรมชาติของ tRPC และความท้าทายในการทดสอบ
ก่อนที่เราจะลงลึกถึงกลยุทธ์การทดสอบ จำเป็นอย่างยิ่งที่ต้องเข้าใจว่า tRPC ทำงานอย่างไร และอะไรทำให้การทดสอบแตกต่างจาก API แบบดั้งเดิม
1.1 สถาปัตยกรรมของ tRPC
tRPC เป็นเฟรมเวิร์กที่ช่วยให้คุณสร้าง API แบบ RPC (Remote Procedure Call) โดยใช้ TypeScript เป็นภาษาหลัก จุดเด่นคือการ infer types จาก backend สู่ frontend โดยอัตโนมัติ ทำให้ไม่ต้องประกาศ types ซ้ำ ซึ่งช่วยลดความผิดพลาดและเพิ่มประสิทธิภาพในการพัฒนา
โครงสร้างพื้นฐานของ tRPC ประกอบด้วย:
- Router: ตัวกำหนดเส้นทางของ API endpoint
- Procedure: ฟังก์ชันที่ถูกเรียกใช้เมื่อมีการเรียก endpoint
- Context: ข้อมูลที่ถูกส่งผ่านทุก request เช่น authentication, database connection
- Middleware: ฟังก์ชันที่ทำงานก่อน/หลัง procedure (เช่น การตรวจสอบสิทธิ์)
1.2 ความท้าทายเฉพาะของ tRPC
การทดสอบ tRPC มีความท้าทายที่แตกต่างจากการทดสอบ REST API ดังนี้:
| ประเด็น | REST API | tRPC |
|---|---|---|
| การเรียก API | HTTP Request (GET, POST, PUT, DELETE) | ฟังก์ชัน TypeScript โดยตรง |
| การจัดการ Type | ต้องประกาศ types ซ้ำ (เช่น OpenAPI, Zod) | Types ถูก infer โดยอัตโนมัติ |
| การทดสอบ Integration | ต้องใช้ HTTP client (Supertest, Axios) | เรียกใช้ router โดยตรง |
| การ Mock | Mock HTTP layer | Mock function call |
| Error Handling | HTTP Status Codes | TRPCError (type-safe) |
ความท้าทายหลักคือการที่ tRPC เชื่อมต่อ frontend และ backend อย่างแนบแน่น ทำให้การแยกส่วนเพื่อทดสอบต้องใช้เทคนิคที่ซับซ้อนขึ้น
2. กลยุทธ์การทดสอบ tRPC แบบหลายชั้น (Layered Testing Strategy)
การทดสอบ tRPC ที่มีประสิทธิภาพต้องครอบคลุมหลายชั้น ตั้งแต่ unit test ไปจนถึง e2e test โดยแต่ละชั้นมีวัตถุประสงค์และเครื่องมือที่แตกต่างกัน
2.1 Unit Test สำหรับ Procedure แต่ละตัว
Unit Test เป็นชั้นพื้นฐานที่สุด โดยมุ่งเน้นการทดสอบ procedure แต่ละตัวแยกจากกัน โดย mocking dependencies ทั้งหมด เช่น database, external API, หรือ context
ตัวอย่างการเขียน Unit Test ด้วย Vitest:
ข้อดีของ Unit Test คือความเร็วและความแม่นยำในการระบุจุดบกพร่อง แต่ข้อเสียคือไม่สามารถตรวจจับปัญหาใน integration ได้
2.2 Integration Test สำหรับ Router
Integration Test จะทดสอบการทำงานร่วมกันของหลายๆ procedure ภายใน router เดียวกัน รวมถึง middleware และ context โดยอาจใช้ database จริงหรือ in-memory database แทนการ mock
ตัวอย่าง Integration Test ด้วย tRPC’s caller:
การทดสอบแบบนี้ช่วยให้มั่นใจว่า router ทำงานได้ถูกต้องทั้งในแง่ของ business logic และ error handling
3. การจัดการ Context และ Middleware ในการทดสอบ
หนึ่งในความท้าทายที่พบบ่อยในการทดสอบ tRPC คือการจัดการ context และ middleware ซึ่งมักเกี่ยวข้องกับการ authentication, authorization, และการเชื่อมต่อฐานข้อมูล
3.1 การสร้าง Test Context
การสร้าง context สำหรับการทดสอบควรแยกออกจาก production context เพื่อให้สามารถควบคุม dependencies ได้อย่างเต็มที่
3.2 การทดสอบ Middleware
Middleware ใน tRPC มักใช้สำหรับตรวจสอบสิทธิ์ (authorization) หรือการ validate input การทดสอบ middleware ควรแยกออกจาก procedure และทดสอบในบริบทต่างๆ
ตัวอย่างการทดสอบ middleware ที่ใช้ตรวจสอบ role:
4. การทดสอบ Error Handling และ Edge Cases
การจัดการข้อผิดพลาดเป็นส่วนสำคัญของแอปพลิเคชัน tRPC การทดสอบควรครอบคลุมทั้ง TRPCError ที่กำหนดเอง และข้อผิดพลาดที่ไม่คาดคิด
4.1 การทดสอบ TRPCError ที่กำหนดเอง
tRPC มี error codes มาตรฐาน เช่น NOT_FOUND, UNAUTHORIZED, FORBIDDEN, BAD_REQUEST, INTERNAL_SERVER_ERROR การทดสอบควรตรวจสอบทั้ง code และ message
4.2 การทดสอบ Edge Cases
Edge cases ที่ควรทดสอบสำหรับ tRPC ได้แก่:
- Input ที่มีค่าขอบเขต (boundary values) เช่น string ยาวมาก, ตัวเลขติดลบ
- การเรียก procedure ที่ไม่มีอยู่ (invalid path)
- การส่งข้อมูลซ้ำ (idempotency) โดยเฉพาะ mutation
- การทำงานพร้อมกัน (concurrency) เช่น การ update record เดียวกันจากหลาย request
- การ timeout หรือ network error (สำหรับการทดสอบ client-side)
5. การทดสอบ Client-side Integration
การทดสอบฝั่ง client ที่เรียกใช้ tRPC มีความสำคัญไม่แพ้ฝั่ง server โดยเฉพาะอย่างยิ่งเมื่อ tRPC มี type safety ที่แข็งแกร่ง
5.1 การ Mock tRPC Client
ในการทดสอบ frontend component ที่ใช้ tRPC hooks เราสามารถ mock tRPC client ได้โดยใช้ utilities ที่ tRPC จัดเตรียมไว้ให้
5.2 การทดสอบ Mutation ด้วย Optimistic Updates
tRPC รองรับ optimistic updates ซึ่งช่วยให้ UI ตอบสนองได้ทันที การทดสอบกรณีนี้ต้องตรวจสอบทั้ง optimistic state และ final state หลังจาก server ตอบกลับ
6. การเปรียบเทียบเครื่องมือและแนวทางปฏิบัติที่ดีที่สุด
ในการเลือกเครื่องมือสำหรับทดสอบ tRPC มีหลายตัวเลือก แต่ละตัวมีข้อดีข้อเสียแตกต่างกันไป
6.1 เปรียบเทียบ Testing Frameworks
| เครื่องมือ | จุดเด่น | จุดด้อย | เหมาะกับ |
|---|---|---|---|
| Vitest | เร็ว, รองรับ ESM, เข้ากับ Vite/Next.js | ยังใหม่, ecosystem น้อยกว่า Jest | โปรเจกต์ที่ใช้ Vite หรือ modern stack |
| Jest | 成熟, มี community ขนาดใหญ่, plugins มาก | ช้า, การตั้งค่าซับซ้อน, ESM support จำกัด | โปรเจกต์ legacy หรือต้องการ stability |
| Playwright | E2E testing ที่แข็งแกร่ง, รองรับหลาย browser | ช้า, ใช้ทรัพยากรมาก | การทดสอบ end-to-end และ visual testing |
| Supertest (สำหรับ tRPC) | ทดสอบ HTTP layer จริง | ต้องตั้งค่า server, ช้ากว่า direct call | การทดสอบ integration ที่ต้องใช้ HTTP |
6.2 Best Practices สำหรับการทดสอบ tRPC
จากประสบการณ์ในโปรเจกต์จริง เราได้รวบรวมแนวทางปฏิบัติที่ดีที่สุดดังนี้:
- แยก business logic ออกจาก procedure – เขียน logic ใน service layer ที่แยกออกมา เพื่อให้สามารถทดสอบ unit test ได้โดยไม่ต้องพึ่ง tRPC
- ใช้ dependency injection – ส่ง dependencies (เช่น database client, external API) ผ่าน context แทนการ import โดยตรง
- ทดสอบ middleware แยกต่างหาก – middleware ควรถูกทดสอบเป็นหน่วยอิสระ ก่อนนำไปใช้ใน router
- ใช้ test database แยก – สำหรับ integration test ควรใช้ database ที่แยกจาก production เช่น SQLite in-memory หรือ Docker container
- สร้าง test utilities – สร้าง helper functions สำหรับการสร้าง context, mock data, และ caller เพื่อลด code ซ้ำซ้อน
- ทดสอบทั้ง success และ failure paths – อย่าลืมทดสอบกรณี error, edge cases, และ unexpected inputs
- ใช้ type safety ให้เป็นประโยชน์ – tRPC ให้ type safety ที่แข็งแกร่ง ใช้ TypeScript compiler เป็นเครื่องมือทดสอบเบื้องต้น
- จัดลำดับความสำคัญของ test layers – 80% unit test, 15% integration test, 5% e2e test (ตาม Test Pyramid)
7. กรณีศึกษาจากโลกจริง (Real-World Use Cases)
เพื่อให้เห็นภาพชัดเจนยิ่งขึ้น เราจะนำเสนอกรณีศึกษาจากโปรเจกต์จริงที่ใช้ tRPC และกลยุทธ์การทดสอบที่เราได้กล่าวถึง
7.1 กรณีศึกษา: แพลตฟอร์ม E-Commerce ขนาดกลาง
ความท้าทาย: ทีมพัฒนาประสบปัญหาการทดสอบที่ใช้เวลานาน เพราะต้องทดสอบทั้ง frontend และ backend แยกจากกัน และมักพบข้อผิดพลาดที่เกิดจาก type mismatch ระหว่างสองฝั่ง
แนวทางแก้ไข:
- ใช้ tRPC เพื่อให้ type safety ระหว่าง frontend-backend
- สร้าง test suite ที่ครอบคลุม 3 ระดับ:
- Unit test สำหรับ service layer (business logic)
- Integration test สำหรับ tRPC router (รวม middleware และ context)
- Component test สำหรับ React components ที่ใช้ tRPC hooks
- ใช้ Vitest + Testing Library สำหรับ frontend
- ใช้ in-memory SQLite สำหรับ integration test เพื่อความเร็ว
ผลลัพธ์: ลดเวลาในการ debug ลง 60%, เพิ่ม code coverage จาก 45% เป็น 85%, และลดจำนวนบั๊กที่พบใน production ลง 70%
7.2 กรณีศึกษา: ระบบจัดการเอกสารภายในองค์กร
ความท้าทาย: ระบบมี workflow ที่ซับซ้อน เกี่ยวข้องกับหลายขั้นตอนและการอนุมัติจากผู้ใช้หลายระดับ การทดสอบ manual ใช้เวลานานและเกิดข้อผิดพลาดบ่อย
แนวทางแก้ไข:
- ใช้ tRPC mutation แบบมี middleware สำหรับ authorization
- เขียน integration test ที่จำลอง workflow ทั้งหมด ตั้งแต่สร้างเอกสาร ไปจนถึงอนุมัติ
- ใช้ Playwright สำหรับ e2e test เพื่อทดสอบ UI flow
- สร้าง test data factory สำหรับสร้างข้อมูลทดสอบที่ซับซ้อน
ผลลัพธ์: การทดสอบ regression ที่เคยใช้เวลา 2 วัน ลดลงเหลือ 30 นาที, สามารถ deploy ได้บ่อยขึ้น (จากเดือนละครั้งเป็นสัปดาห์ละครั้ง)
8. เครื่องมือและเทคนิคขั้นสูง
สำหรับทีมที่ต้องการยกระดับการทดสอบ tRPC ไปอีกขั้น มีเครื่องมือและเทคนิคที่น่าสนใจดังนี้
8.1 การใช้ tRPC Server-side Caller
หนึ่งในฟีเจอร์ที่ทรงพลังของ tRPC คือความสามารถในการเรียก procedure โดยตรงจากฝั่ง server โดยไม่ต้องผ่าน HTTP ซึ่งช่วยให้การทดสอบ integration ทำได้ง่ายและเร็วขึ้น
8.2 การใช้ Snapshot Testing สำหรับ tRPC Response
Snapshot testing สามารถใช้เพื่อตรวจสอบว่า response จาก tRPC procedure ไม่เปลี่ยนแปลงโดยไม่ตั้งใจ
8.3 การใช้ Faker.js สำหรับสร้าง Test Data
การสร้างข้อมูลทดสอบที่สมจริงช่วยให้การทดสอบครอบคลุมกรณีต่างๆ ได้ดีขึ้น
9. การตั้งค่า CI/CD สำหรับ tRPC Testing
การทดสอบอัตโนมัติใน CI/CD pipeline เป็นสิ่งจำเป็นสำหรับทีมที่ต้องการ quality assurance อย่างต่อเนื่อง
9.1 ตัวอย่าง GitHub Actions Workflow
9.2 การตั้งค่า Test Runner สำหรับ CI
ควรปรับแต่งการตั้งค่า Vitest หรือ Jest ให้เหมาะสมกับสภาพแวดล้อม CI:
10. ข้อผิดพลาดที่พบบ่อยและวิธีแก้ไข
จากการทำงานกับ tRPC testing ในหลายโปรเจกต์ เราพบข้อผิดพลาดที่พบบ่อยดังนี้:
| ปัญหา | สาเหตุ | วิธีแก้ไข |
|---|---|---|
| TypeError: Cannot read properties of undefined (reading ‘query’) | ไม่ได้สร้าง caller อย่างถูกต้อง หรือ context ขาด dependencies ที่จำเป็น | ตรวจสอบว่า createCaller ถูกเรียกด้วย context ที่สมบูรณ์ |
| Test ใช้เวลานานเกินไป | ใช้ database จริง หรือมีการทำ network call | เปลี่ยนเป็น in-memory database, mock external APIs |
| Test flaky (บางครั้งผ่าน บางครั้งไม่ผ่าน) | การทำงาน async
คำเตือนความเสี่ยง: การลงทุนมีความเสี่ยง ผู้ลงทุนควรศึกษาข้อมูลและประเมินความเสี่ยงก่อนตัดสินใจลงทุน 
 Log In
|
