> For the complete documentation index, see [llms.txt](https://www.saladpuk.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.saladpuk.com/software-testing/tdd101/test-cases.md).

# 2.Test cases เขาเขียนกันยังไงนะ

💬 ก่อนที่เราจะเขียนโค้ดเราจะต้องเขียน test cases เสียก่อน ดังนั้นเราจะมาดูกันว่าทำไมจะต้องเขียน test cases และถ้าจะต้องเขียนมันจะต้องเริ่มต้นยังไงบ้างนะ

{% embed url="<https://www.youtube.com/watch?v=pyGgI9AsxiU&list=PLUjAn8nwWniiL3ToFK8PfmAo8U6IoGAkg&index=2>" %}

## 🎯 สรุปสั้นๆ

### 👨‍🚀 ข้อดีในการเขียน test cases

1. ทุกคนในทีมและลูกค้าเข้าใจตรงกันว่า feature นั้นคืออะไร จะได้ไม่เสียเวลาเขียนโค้ดที่ไม่ใช่ของที่ลูกค้าอยากได้
2. ถ้าคนในทีมเข้าใจผิด มันจะถูกแก้ไขก่อนที่เราจะเขียนโค้ดเสียอีก เลยไม่ทำให้เราเสียเวลาไปนั่งไล่โค้ด

### 👨‍🚀 วิธีเขียน test cases

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

| กลุ่ม                 | ความหมาย                                                            |
| --------------------- | ------------------------------------------------------------------- |
| **Normal cases**      | กรณีที่**เกิดขึ้นบ่อยๆ**ในระบบ หรือ สิ่งที่ระบบควรจะต้องทำได้       |
| **Alternative cases** | กรณีที่**เกิดขึ้นไม่ค่อยบ่อย** นานๆจะเกิดขึ้นครั้ง                  |
| **Exception cases**   | กรณีที่เจอ**ข้อผิดแปลกจากสิ่งที่มันควรจะเป็น** ระบบจะต้องทำอะไรบ้าง |

{% hint style="success" %}
**เวลาคิดเคส**\
ให้คิดทีละกลุ่มไล่จาก Normal cases, Alternative cases และ Exception cases ตามลำดับ **ควรเน้นไปที่ Normal cases เสียก่อนเพราะ 80% ของระบบจะต้องเจอเรื่องพวกนี้**
{% endhint %}

{% hint style="danger" %}
**เวลาคิดเคส**\
**ไม่ต้องคิดจนมันครอบคลุมทุกอย่าง 100%** นะ ในช่วงแรกๆ**เอาแค่พอประมาณเสียก่อน แล้วค่อยกลับมาเติมเคสที่เหลือทีหลัง**ก็ได้ ไม่งั้นเราจะไม่ได้ทำงานซะที และเคสที่คิดอันหลังๆส่วนใหญ่มีโอกาสน้อยที่จะได้เจอ เลยทำให้เสียเวลาในการคิดโดยใช่เหตุ
{% endhint %}

\*\*\*\*