เอกสาร การทดสอบ และการสร้าง

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

จากการออกแบบสู่เซอร์วิสที่ทำงานได้จริง

flowchart LR
  D[Design: resources, methods, errors] --> S[Spec: OpenAPI]
  S --> I[Implement: TypeScript + Hono]
  I --> T[Test: unit / integration / contract]
  T --> Doc[Docs from the spec]
  Doc --> D

spec การสร้างจริง และการทดสอบต่างเสริมกันและกัน

spec คือบานพับสำคัญ ทำหน้าที่บันทึก contract ไว้ให้คนที่มาใช้ API ใช้ generate code ฝั่ง client และเอกสารได้ แถมยังเป็นตัวอ้างอิงให้ test ของคุณเทียบว่าของจริงตรงกับที่ประกาศไว้หรือไม่

โมดูลนี้ครอบคลุมอะไรบ้าง

OpenAPI — อธิบาย API เป็น contract ที่เครื่องอ่านได้
Testing APIs — การทดสอบแบบ unit, integration และ contract
Building with Hono — การสร้างจริงด้วย TypeScript ที่ผสานเป็นหนึ่งเดียว
Best-practices recap — เช็กลิสต์รวบทุกอย่างที่คุณได้เรียนรู้มา

spec ของ OpenAPI มีบทบาทอย่างไรต่อเอกสาร การทดสอบ และ client? ใช้แทนที่การสร้างจริงได้เลย เป็น single source of truth ของ contract ที่สิ่งอื่นอ้างอิงตาม มีไว้สร้างเอกสารเท่านั้น เป็นแค่ของประดับ จะมีหรือไม่มีก็ได้

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