วิธีให้ Gemini เขียน Unit Test อัตโนมัติ

Google Gemini สามารถช่วยสร้าง Unit Test จาก Source Code ที่มีอยู่ได้ โดยผู้ใช้สามารถส่ง Function, Class, Module หรือ Codebase ให้ Gemini วิเคราะห์ แล้วสั่งให้สร้าง Test Case สำหรับ Normal Case, Boundary Case, Invalid Input, Error Case และ Regression Bug ได้อัตโนมัติ

อย่างไรก็ตาม คำว่า “อัตโนมัติ” ในที่นี้หมายถึง Gemini ช่วย Generate Test Code จาก Context ที่ให้มา ไม่ได้หมายความว่า Test ทุกชุดจะถูก Run และยืนยันว่าถูกต้องโดยอัตโนมัติเสมอไป หลัง Gemini สร้าง Test แล้ว Developer ยังต้องนำ Test ไป Run ด้วย Test Framework และ Environment จริงของ Project

Workflow ที่เหมาะสมคือ อ่าน Code → ระบุ Expected Behavior → สร้าง Test Cases → Generate Unit Test → Run → ตรวจ Failure → ปรับ Test/Code → Run ทั้ง Test Suite

❶ 🧪 Unit Test คืออะไร

Unit Test คือการทดสอบส่วนเล็ก ๆ ของโปรแกรมแยกจากระบบทั้งหมด

Unit อาจเป็น

• Function
• Method
• Class
• Module ขนาดเล็ก
• Business Logic

ตัวอย่าง Function

def calculate_total(price, quantity):
    return price * quantity

Unit Test จะตรวจว่า Function นี้คืนค่าถูกต้องหรือไม่เมื่อได้รับ Input ต่าง ๆ

เช่น

price = 100
quantity = 2
expected = 200

จุดประสงค์คือจับ Bug ให้เร็ว ก่อน Code ถูกนำไปรวมกับระบบส่วนอื่น

❷ 🤖 Gemini เขียน Unit Test ได้ไหม

ได้ Gemini สามารถช่วย

• อ่าน Function
• วิเคราะห์ Input/Output
• หา Edge Case
• สร้าง Test Case
• เขียน Unit Test Code
• สร้าง Mock
• สร้าง Test Data
• วิเคราะห์ Test Failure
• เพิ่ม Regression Test
• Review Test Coverage เบื้องต้น
• Refactor Test Code
• อธิบายว่า Test แต่ละตัวตรวจอะไร

ถ้า Project มีหลายไฟล์ สามารถให้ Gemini อ่าน Code Folder หรือ GitHub Repository เพื่อเข้าใจ Dependency และ Test Style เดิมของ Project ก่อนสร้าง Test เพิ่มได้

❸ 🧠 อย่าเริ่มด้วย “เขียน Test ให้ทั้งหมด”

คำสั่งนี้กว้างเกินไป

Gemini อาจ

• เลือก Framework ผิด
• Mock ทุกอย่างเกินจำเป็น
• Test Implementation Detail
• สร้าง Test ซ้ำ
• พลาด Business Rule
• สร้าง Assertion ที่ไม่ตรง Requirement

ควรเริ่มด้วย

“อ่าน Function นี้ก่อน แล้วอธิบาย Behavior ที่ควรถูก Test โดยยังไม่เขียน Test Code”

เมื่อได้รายการ Test Case แล้วจึงสั่งสร้าง Code

❹ 📋 Prompt แม่แบบสำหรับสร้าง Unit Test

ใช้ Prompt นี้ได้กับหลายภาษา

“ช่วยสร้าง Unit Test สำหรับ Code นี้

Language:
[ระบุภาษา]

Test Framework:
[ระบุ Framework ที่ Project ใช้อยู่]

Source Code:
[แนบ Code]

Expected Behavior:
[อธิบาย Requirement]

ให้ทำตามลำดับ:

1. อธิบายหน้าที่ของ Code
2. ระบุ Input และ Output
3. สร้างรายการ Test Case ก่อน
4. แบ่งเป็น Normal, Boundary, Invalid และ Error Case
5. ระบุ Dependency ที่ต้อง Mock
6. เขียน Unit Test ตาม Framework ที่กำหนด
7. ไม่ Test Implementation Detail ถ้าไม่จำเป็น
8. ตั้งชื่อ Test ให้สื่อ Behavior
9. อธิบาย Assertion สำคัญ
10. ระบุ Case ที่ยังไม่สามารถ Test ได้จากข้อมูลที่มี

ห้ามสร้าง Function หรือ API ที่ไม่มีอยู่จริงใน Project”

Prompt นี้ช่วยให้ Gemini ไม่กระโดดไปสร้าง Test Code ทันที

❺ 🎯 ต้องกำหนด Expected Behavior ก่อน

Unit Test ที่ดีไม่ได้ตรวจว่า

Code ปัจจุบันทำอะไร

เพียงอย่างเดียว

แต่ต้องตรวจว่า

Code ควรทำอะไรตาม Requirement

สมมติ Function

def discount(price, percent):
    return price - percent

ถ้า Requirement คือ

“percent หมายถึงเปอร์เซ็นต์ส่วนลด”

ผลลัพธ์ของ

price = 1000
percent = 20

ควรเป็น

800

แม้ Code ปัจจุบันจะคืน

980

Gemini จึงต้องรู้ Requirement เพื่อสร้าง Test ที่จับ Bug ได้

❻ 🧪 สร้าง Test Case ก่อนเขียน Test Code

ตัวอย่าง Function

def divide(a, b):
    return a / b

ก่อน Generate Unit Test ให้ Gemini สร้าง Case เช่น

Normal Case

10 / 2 = 5

Decimal

5 / 2 = 2.5

Negative

-10 / 2 = -5

Zero Numerator

0 / 5 = 0

Zero Denominator

ต้องกำหนดว่า

• Raise Error
• Return ค่าเฉพาะ
• จัดการรูปแบบอื่น

ตาม Requirement

นี่คือเหตุผลว่าทำไม Test Design ควรมาก่อน Test Code

❼ 🟢 Normal Case คืออะไร

Normal Case คือสถานการณ์ที่ผู้ใช้หรือโปรแกรมใช้งานตามปกติ

ตัวอย่าง Function คำนวณราคา

price = 500
quantity = 2

Expected

1000

Prompt

“สร้าง Happy Path หรือ Normal Case ที่สำคัญที่สุดก่อน”

อย่ามีแต่ Edge Case จนลืม Behavior หลักของ Function

❽ 📏 Boundary Case สำคัญมาก

Bug จำนวนมากเกิดตรงค่าขอบเขต

ตัวอย่าง Requirement

“ผู้ใช้อายุ 18 ปีขึ้นไปสมัครได้”

ควร Test

17
18
19

ไม่ใช่ Test แค่

20
30

Prompt

“ค้นหาค่าขอบเขตทั้งหมดจาก Condition ใน Function นี้ และสร้าง Test ก่อนและหลัง Boundary”

เหมาะกับ

• อายุ
• ราคา
• Discount
• คะแนน
• จำนวนสินค้า
• Date
• Limit
• Pagination

❾ ❌ Invalid Input ต้อง Test

ตัวอย่าง Function รับจำนวนสินค้า

Input ที่ควรตรวจอาจมี

0
-1
None
"10"
"abc"
[]

ขึ้นกับภาษากับ Requirement

Prompt

“แยก Invalid Input ที่ Application ควร Reject ออกจาก Input ที่ควร Convert อัตโนมัติ”

อย่าให้ Gemini ตัดสินเองว่า String "10" ควรถูก Convert เป็น Number หรือ Error หาก Requirement ไม่ได้กำหนด

❿ ⚠️ Error Case ต้องกำหนด Behavior

สมมติ Function อ่านไฟล์

อาจเกิด

• File Not Found
• Permission Error
• Invalid Format
• Empty File

Unit Test ควรตรวจว่า Code

• Throw Exception
• Return Result
• Log Error

อย่างไรตาม Design

Prompt

“สร้าง Unit Test ที่ตรวจ Error Contract ของ Function นี้ แทนการตรวจเพียงว่า Code ไม่ Crash”

🐍 วิธีให้ Gemini เขียน Unit Test Python

Python มี Test Framework หลายแบบ เช่น

• unittest
• pytest

หาก Project ใช้ Framework อยู่แล้วควรใช้ตัวเดิม

ตัวอย่าง Source

def add(a: int, b: int) -> int:
    return a + b

Test ด้วย pytest

from app import add


def test_add_two_positive_numbers():
    assert add(2, 3) == 5

Prompt

“เขียน pytest สำหรับ Function add() โดยสร้าง Test Case สำหรับ Positive, Negative และ Zero”

อย่าให้ Gemini เพิ่ม pytest เองถ้า Project ใช้ unittest

ควรตรวจ Existing Test ก่อนเสมอ

🧪 Parameterized Test ใน Python

หาก Case ใช้ Logic เดียวกันแต่ Input ต่าง สามารถใช้ Parameterization ตาม Framework

ตัวอย่าง pytest

import pytest

from app import add


@pytest.mark.parametrize(
    ("a", "b", "expected"),
    [
        (2, 3, 5),
        (0, 0, 0),
        (-2, 3, 1),
    ],
)
def test_add(a, b, expected):
    assert add(a, b) == expected

Prompt

“รวม Test Case ที่มี Structure เดียวกันเป็น Parameterized Test โดยยังให้ชื่อและข้อมูลอ่านเข้าใจง่าย”

ช่วยลด Test Code ซ้ำ

⚙️ วิธีให้ Gemini เขียน Unit Test JavaScript

JavaScript Project อาจใช้ Framework เช่น

• Jest
• Vitest
• Node Test Runner
• Framework-specific Testing Tools

ต้องให้ Gemini ตรวจ package.json และ Test Config ก่อน

ตัวอย่าง Function

export function multiply(a, b) {
  return a * b;
}

แนวคิด Test

import { multiply } from "./math.js";

test("multiplies two numbers", () => {
  expect(multiply(3, 4)).toBe(12);
});

แต่ Syntax จริงควรตรงกับ Framework ของ Project

Prompt

“ตรวจ package.json ก่อน แล้วใช้ Test Framework ที่ติดตั้งอยู่แล้ว ห้ามเพิ่ม Framework ใหม่”

🐘 วิธีให้ Gemini เขียน Unit Test PHP

PHP Project จำนวนมากใช้ PHPUnit

ตัวอย่าง Source

function calculateTotal(float $price, int $quantity): float
{
    return $price * $quantity;
}

ก่อน Generate Test ควรให้ Gemini ตรวจ

• composer.json
• PHPUnit Version
• Namespace
• Autoload
• Test Directory

Prompt

“สร้าง PHPUnit Test สำหรับ Function นี้โดยใช้ Version และ Project Structure เดิม ห้ามสร้าง Namespace ใหม่โดยเดาเอง”

ช่วยลดปัญหา Test Code ถูกแต่ Run ไม่ได้ใน Project จริง

☕ Framework ไหนก็ต้องใช้ Version จริง

ไม่ว่าจะเป็น

• Python
• JavaScript
• PHP
• Java
• C#
• Go

Test Framework สามารถเปลี่ยน Syntax และ API ตาม Version

ดังนั้นควรส่ง

Language Version
Framework
Framework Version
Existing Test Example

ให้ Gemini ก่อน

โดยเฉพาะ Project เก่าที่อาจไม่ได้ใช้ Syntax รุ่นล่าสุด

📂 ให้ Gemini อ่าน Existing Tests ก่อน

นี่เป็นหนึ่งในวิธีที่ดีที่สุด

ส่ง Test File ตัวอย่างของ Project แล้วสั่ง

“อ่าน Test ที่มีอยู่ก่อน แล้วสร้าง Test ใหม่โดยใช้ Style, Naming, Fixture, Mock และ Assertion Pattern เดียวกัน”

ข้อดีคือ Test ใหม่เข้ากับ Codebase เดิมมากกว่า

เช่น Project อาจมี Convention

tests/unit/
tests/integration/

หรือ Naming

test_user_service.py
UserServiceTest.php
user.service.test.js

Gemini ควรยึดรูปแบบเดิม

🏷️ ตั้งชื่อ Test ให้บอก Behavior

ชื่อที่ไม่ดี

test1
test_user
test_function

ชื่อที่ดีกว่า

test_returns_zero_when_cart_is_empty

หรือ

rejects_order_when_stock_is_insufficient

Prompt

“ตั้งชื่อ Test ให้บอก Behavior และ Condition โดยไม่อิงชื่อ Implementation ภายในเกินจำเป็น”

ชื่อ Test ที่ดีทำให้ Test Suite ทำหน้าที่เป็น Documentation ได้ด้วย

🆚 Test Behavior ไม่ใช่ Implementation

สมมติ Function ภายในใช้

sort()

ถ้า Requirement คือ

“คืนรายการเรียงตามราคา”

Test ควรตรวจ Output เรียงถูก

ไม่จำเป็นต้องตรวจว่า Function เรียก sort() กี่ครั้ง

เพราะถ้า Refactor Algorithm ในอนาคต Behavior ยังเหมือนเดิม Test ไม่ควร Fail

หลักคือ

Test What, not How

ในกรณีที่ไม่จำเป็นต้องล็อก Implementation

🎭 Mock คืออะไร

Mock ใช้แทน Dependency ที่ไม่ต้องการเรียกจริงใน Unit Test

ตัวอย่าง Dependency

• Database
• Email
• Payment API
• External HTTP API
• File System
• Clock
• Random Generator

สมมติ Function

createOrder()
↓
saveDatabase()
↓
sendEmail()

Unit Test ของ Business Logic อาจไม่ต้องส่ง Email จริง

จึง Mock Email Service

⚠️ อย่า Mock ทุกอย่าง

Over-mocking ทำให้ Test ผ่านแม้ Integration จริงพัง

Prompt

“ระบุเฉพาะ Dependency ที่จำเป็นต้อง Mock และอธิบายว่าทำไม ส่วน Pure Function หรือ Value Object ไม่ต้อง Mock”

หลักง่าย ๆ คือ

Mock Boundary

ไม่ใช่ Mock ทุก Function

🌐 ไม่ควรเรียก API จริงใน Unit Test ทุกครั้ง

หาก Unit Test เรียก External API จริง อาจเกิด

• Test ช้า
• Network Fail
• Rate Limit
• Cost
• Data เปลี่ยน
• Result ไม่แน่นอน

ควร Mock API Response ใน Unit Test

ส่วนการทดสอบ API จริงอาจอยู่ใน

• Integration Test
• Contract Test
• End-to-End Test

ตาม Architecture

🗄️ Database ก็เหมือนกัน

ถ้า Unit Test Business Logic แล้วต้องเปิด Database จริงทุกครั้ง Test อาจไม่ใช่ Unit Test ที่แยกจาก Dependency แล้ว

แต่ไม่ใช่ว่า Database ห้ามใช้ในการ Test ทั้งหมด

ควรแบ่ง

Unit Test

แยก Logic

Integration Test

ตรวจการทำงานร่วมกับ Database จริงหรือ Test Database

การแบ่ง Layer ทำให้ Test Suite มีจุดประสงค์ชัด

🧠 ให้ Gemini บอกก่อนว่าควรเป็น Unit หรือ Integration Test

Prompt

“สำหรับ Test Case นี้ช่วยจัดประเภทก่อนว่าเหมาะเป็น Unit Test, Integration Test หรือ End-to-End Test พร้อมเหตุผล”

ตัวอย่าง

“User Login ต้องตรวจ Password Hash + Database + Session”

อาจมีหลาย Layer

ไม่ควรบังคับทุกอย่างให้เป็น Unit Test

🧪 วิธีสร้าง Regression Test จาก Bug

นี่เป็น Use Case ที่มีประโยชน์มากที่สุดของ Gemini

สมมติ Bug คือ

“User ที่ไม่มี Profile ทำให้หน้า Account Crash”

Workflow

❶ อธิบาย Bug

❷ ให้ Gemini สร้าง Test ที่ Reproduce

❸ Run Test

ต้อง Fail ก่อน

❹ แก้ Code

❺ Run Test

ต้อง Pass

Prompt

“สร้าง Regression Test สำหรับ Bug นี้ โดย Test ต้อง Fail กับ Code ปัจจุบันและ Pass หลัง Root Cause ถูกแก้”

วิธีนี้ช่วยป้องกัน Bug เดิมกลับมา

🔴 Test ควร Fail ก่อนแก้ Bug

ถ้าสร้าง Regression Test แล้ว Test ผ่านทั้งที่ Bug ยังมีอยู่

อาจแปลว่า

• Test ไม่ได้ Reproduce Bug
• Assertion ผิด
• Setup ไม่ตรง
• Test เรียกผิด Code Path

อย่ารีบแก้ Production Code

ควรตรวจ Test ก่อน

📊 Coverage คืออะไร

Code Coverage ช่วยบอกว่า Test Execute Code ส่วนใดบ้าง

ตัวเลขอาจอยู่ในรูป

Statement Coverage
Branch Coverage
Function Coverage
Line Coverage

แต่ Coverage สูงไม่ได้หมายความว่า Test ดีเสมอไป

Project อาจมี Coverage 100% แต่ Assertion อ่อนมากจนจับ Bug ไม่ได้

ดังนั้นควรใช้ Coverage เป็น Signal ไม่ใช่ Goal เพียงอย่างเดียว

🎯 อย่าสั่ง Gemini ว่า “ทำ Coverage 100%” อย่างเดียว

AI อาจสร้าง Test จำนวนมากเพียงเพื่อ Execute ทุกบรรทัด

แต่ Test อาจไม่มีคุณค่าทาง Business

Prompt ที่ดีกว่า

“ดู Coverage Gap แล้วเลือก Test Case ที่มีความเสี่ยงทาง Business สูงที่สุดก่อน”

Priority ควรเป็น

Critical Behavior
↓
Error Handling
↓
Boundary
↓
Regression
↓
Less-important code

🔀 Branch Coverage สำคัญอย่างไร

ตัวอย่าง

def shipping_fee(total):
    if total >= 1000:
        return 0

    return 50

ถ้า Test มีเพียง

total = 1500

ก็ Test ได้เพียง Branch หนึ่ง

ควรมีอีก Case

total = 500

และ Boundary

total = 1000
999

Prompt

“ค้นหา Condition ทุก Branch แล้วสร้าง Test ครอบคลุม Boundary ของแต่ละ Branch”

📋 Table-driven Test

Function ที่มี Input/Expected Output จำนวนมากเหมาะกับ Test Table

ตัวอย่าง

Input	Expected
0	0
1	10
10	100
-1	Error

Gemini สามารถช่วยสร้างตารางก่อนแปลงเป็น Parameterized Test

ทำให้ Review Business Rule ได้ง่าย

🕒 Test เวลาอย่างไร

Function ที่ใช้

now()
today()
currentTime()

อาจ Test ยาก เพราะผลเปลี่ยนตามเวลา

แนวทางที่ดีคือแยก Clock Dependency ออกจาก Business Logic ตาม Architecture

Prompt

“Refactor Function นี้ให้ Test เรื่องเวลาได้โดยไม่พึ่งเวลาจริงทุกครั้ง และสร้าง Test สำหรับก่อน/หลัง Deadline”

ไม่ควรใช้ Sleep เพื่อ Test Logic เวลาโดยไม่จำเป็น

🎲 Random ก็ทำให้ Test ไม่นิ่ง

ถ้า Function ใช้ Random

Test อาจ Pass บ้าง Fail บ้าง

เรียกว่า Flaky Test

Prompt

“ตรวจ Function นี้ว่ามี Random Dependency หรือไม่ และออกแบบให้ Test Deterministic โดยไม่เปลี่ยน Behavior ที่ผู้ใช้เห็น”

อาจใช้ Seed หรือ Dependency Injection ตามภาษาและ Architecture

⚠️ Flaky Test คืออะไร

Flaky Test คือ Test ที่

Code ไม่เปลี่ยน
แต่บางครั้ง Pass
บางครั้ง Fail

สาเหตุอาจมาจาก

• Time
• Random
• Network
• Shared State
• Database
• Concurrency
• Test Order
• File System

Prompt

“วิเคราะห์ Test นี้ว่ามี Source ของ Non-determinism ตรงไหน”

Gemini สามารถช่วยลดพื้นที่ค้นหาได้

🧹 Test ต้อง Cleanup หรือไม่

Test ที่สร้าง File, Record หรือ State อาจต้อง Cleanup หลัง Test

หากไม่ Cleanup

Test อื่นอาจได้รับผลกระทบ

ควรใช้ Setup/Teardown, Fixture หรือ Transaction Pattern ตาม Framework

Prompt

“ตรวจว่า Test นี้มี Shared State หรือ Resource ที่ต้อง Cleanup หลัง Test หรือไม่”

🔒 Unit Test สำหรับ Security Logic

สามารถใช้ Gemini สร้าง Test ให้ Security Requirement เช่น

Authorization

User A ห้ามอ่าน Order ของ User B

Validation

quantity ติดลบต้อง Reject

Input

Role ที่ไม่อยู่ใน Allowlist ต้อง Reject

Authentication

Expired Token ต้องไม่ผ่าน

Test แบบนี้ช่วยล็อก Security Behavior ไว้ใน Codebase

🧪 Test Exception อย่างไร

ไม่ควรเพียงตรวจว่า

“มี Error”

ถ้า Error Contract สำคัญควรตรวจ

• Exception Type
• Error Code
• Message บางส่วนตามความเหมาะสม

ตัวอย่างแนวคิด

divide by zero
→ ValueError

แต่ไม่ควรล็อก Error Message รายละเอียดมากเกินไปหากข้อความไม่ใช่ Public Contract

📥 Test Empty Input

Case ที่มักตกหล่น เช่น

[]
{}
""
None/null

Prompt

“ตรวจทุก Collection/String Input และสร้าง Empty Case หาก Meaningful ตาม Requirement”

Empty Input เป็น Edge Case ที่พบ Bug บ่อย

🔁 Test Duplicate Input

ระบบบางประเภทต้องตรวจ Duplicate เช่น

• Email
• Order
• Payment
• Event
• Form Submission

Prompt

“สร้าง Unit Test หรือ Integration Test สำหรับ Duplicate Request ตาม Layer ที่เหมาะสม”

โดยเฉพาะระบบที่ต้องมี Idempotency

🧾 Test Money ต้องระวัง

ระบบที่คำนวณ

• ราคา
• VAT
• Discount
• Commission
• Currency

ต้องกำหนด

• Decimal Behavior
• Rounding
• Precision

ให้ชัด

Prompt

“สร้าง Test สำหรับค่าการเงินโดยเน้น Rounding Boundary และไม่ใช้ Float Comparison แบบที่ไม่เหมาะกับภาษานี้”

🌍 Test Locale และ Unicode

Application ที่รองรับภาษาไทยหรือหลายภาษาอาจต้อง Test

• Unicode
• Emoji
• Combining Characters
• Date Format
• Locale
• Encoding

ตัวอย่าง

"กรุงเทพฯ"
"ทดสอบ 😊"

Prompt

“เพิ่ม Unicode Test Case โดยไม่เปลี่ยน Requirement ของระบบ”

สำหรับเว็บไซต์ของ comsiam Test ข้อมูลภาษาไทยมีประโยชน์มาก เพราะ Code ที่ผ่านเฉพาะข้อความภาษาอังกฤษอาจยังมีปัญหากับ Encoding หรือ Length Logic ได้

🐙 ใช้ GitHub Repository ให้ Gemini สร้าง Test

หาก Project อยู่บน GitHub สามารถ Import Repository เข้า Gemini Apps แล้วสั่ง

“อ่าน Test Structure ที่มีอยู่ก่อน แล้วค้นหา Service ที่ยังขาด Unit Test”

จากนั้น

“สร้าง Test เฉพาะ UserService โดยใช้ Framework, Mock Style และ Naming เดิมของ Repository”

ข้อดีคือ Gemini เห็น

• Source
• Existing Test
• Dependency
• Configuration

มากกว่าการ Copy Function เดียว

📂 ใช้ Code Folder ก็ได้

หาก Code ยังอยู่ในเครื่อง สามารถใช้ Code Folder เป็น Context

Prompt

“อ่าน Code Folder นี้และหา Module ที่มี Business Logic แต่ไม่มี Test จาก Test Folder ที่มีอยู่”

จากนั้นจัด Priority ตาม

• ความสำคัญ
• Complexity
• Error Risk

ไม่จำเป็นต้อง Generate Test ให้ทุก File พร้อมกัน

🧩 ใช้ Canvas ช่วยสร้างและแก้ Test

Gemini Canvas ปัจจุบันสามารถสร้างและแก้ Code ได้

สามารถใช้ Workflow

Source Code
↓
Canvas
↓
Generate Test
↓
Review
↓
แก้ Test

Canvas ยังมี Code View และ Console สำหรับ App/Code ในสภาพแวดล้อมที่รองรับ

แต่ Unit Test Suite ของ Project จริงยังควรถูก Run ด้วย Test Runner และ Runtime ของ Project เช่น

pytest
npm test
phpunit

หรือคำสั่งที่ Project กำหนด

ไม่ควรถือว่า Test ผ่านเพียงเพราะ Gemini สร้าง Code ได้โดยไม่มี Error ในคำตอบ

▶️ ให้ Gemini บอกคำสั่ง Run Test

Prompt

“ตรวจ Project Config แล้วบอกคำสั่งที่ใช้ Run Unit Test โดยอ้างจาก Configuration ที่มีอยู่ ห้ามเดาคำสั่งถ้าไม่มีข้อมูล”

ตัวอย่างอาจเป็น

pytest

หรือ

npm test

หรือคำสั่งอื่น

แต่ต้องยืนยันจาก Project จริง

🔍 Test Fail แล้วใช้ Gemini วิเคราะห์อย่างไร

ส่ง

• Test Name
• Failure Message
• Stack Trace
• Source
• Expected
• Actual

Prompt

“Test นี้ Fail หลัง Run

Expected:
[…]

Actual:
[…]

Failure:
[…]

วิเคราะห์ก่อนว่า:

1. Production Code ผิด
2. Test ผิด
3. Requirement ไม่ชัด
4. Fixture/Mock ผิด

อย่าแก้ Test ให้ Pass โดยอัตโนมัติ”

นี่สำคัญมาก

เพราะ AI มีแนวโน้มแก้ Assertion เพื่อทำให้ Test ผ่าน ทั้งที่ Production Code อาจมี Bug

🚫 อย่าแก้ Test ให้ผ่านโดยไม่เข้าใจ

ตัวอย่าง

Test คาด

800

Code คืน

980

วิธีที่ผิดคือเปลี่ยน Test เป็น

expected = 980

เพียงเพื่อให้ Test ผ่าน

ต้องกลับไปดู Requirement ก่อนว่าอะไรถูก

กฎคือ

Test Failure คือหลักฐานให้ตรวจ ไม่ใช่สิ่งที่ต้องกำจัดทุกกรณี

🔄 Test ผ่านแล้วต้อง Run Full Suite

หลังเพิ่ม Test หรือแก้ Code

อย่ารันเพียง Test ใหม่

ควร Run

New Test
↓
Related Tests
↓
Full Test Suite

ตามขนาด Project

เพราะ Patch อาจทำ Test อื่นพัง

🧪 Unit Test กับ Integration Test ต่างกันอย่างไร

Unit Test

ทดสอบ Unit แยกจาก Dependency สำคัญ

Integration Test

ทดสอบหลาย Component ทำงานร่วมกัน

ตัวอย่าง

Unit

calculateTotal()

Integration

OrderService
+
Database

Gemini ควรช่วยเลือก Test Level ให้เหมาะกับ Requirement แทนการ Mock ทุก Dependency

🌐 Unit Test กับ End-to-End Test

End-to-End หรือ E2E ทดสอบ Flow จากมุมผู้ใช้มากกว่า

ตัวอย่าง

เปิดเว็บ
↓
Login
↓
เพิ่มสินค้า
↓
Checkout
↓
เห็น Order Success

Unit Test เร็วและเจาะ Logic

E2E ครอบคลุมระบบกว้างกว่าแต่ช้ากว่า

Project ที่ดีมักต้องใช้ Test หลายระดับตามความเสี่ยง

🧱 Test Pyramid คือแนวคิดอะไร

แนวคิดโดยทั่วไปคือมี

E2E Tests
      ▲
Integration Tests
      ▲
Unit Tests

Unit Test มักมีจำนวนมากและเร็ว

Integration น้อยลง

E2E เลือกเฉพาะ Flow สำคัญ

แต่สัดส่วนจริงควรปรับตาม Architecture ไม่จำเป็นต้องยึดตัวเลขตายตัว

📊 ให้ Gemini หา Function ที่ควร Test ก่อน

ไม่ควร Test ตามลำดับไฟล์เสมอไป

Prompt

“จัดอันดับ Function ที่ควรมี Unit Test ก่อนโดยพิจารณา:

• Business Criticality
• Complexity
• Number of Branches
• Bug History
• Security Impact
• Financial Impact
• Reuse Frequency”

ทำให้ Test Investment ไปอยู่จุดที่คุ้มค่ากว่า

💰 Code การเงินควร Priority สูง

ตัวอย่าง

• Invoice
• Tax
• Commission
• Discount
• Payment
• Balance

ควรมี

• Boundary Test
• Decimal Test
• Negative Test
• Rounding Test
• Regression Test

มากกว่าการ Test Getter/Setter ที่ไม่มี Logic

🔐 Authentication และ Authorization ก็ควร Priority สูง

ควร Test Behavior เช่น

Unauthenticated → Reject
Authenticated User → Allowed
Normal User → Admin Action Reject
Admin → Allowed
Expired Session → Reject

ตาม Architecture จริง

♻️ ให้ Gemini Refactor Test ได้ไหม

ได้

Prompt

“Review Test Suite นี้ด้าน:

1. Duplicate Setup
2. Repeated Test Data
3. Weak Assertion
4. Over-mocking
5. Flaky Test
6. Test Naming
7. Slow Test
8. Shared State

ยังไม่แก้ Code ให้จัดอันดับปัญหาก่อน”

จากนั้น Refactor ทีละกลุ่ม

⚠️ Test Code ก็มี Bug ได้

อย่าถือว่า

Production Code = อาจผิด
Test Code = ถูกเสมอ

Test อาจ

• Assert ผิด
• Setup ผิด
• Mock ผิด
• Use Wrong Fixture
• ไม่ Test สิ่งที่คิด
• Pass โดยไม่ได้ Execute Code Path

จึงควร Review Test เช่นเดียวกับ Production Code

🧠 Mutation Testing คืออะไร

ถ้าต้องการตรวจว่า Test แข็งแรงจริงหรือไม่ มีแนวคิด Mutation Testing

คือเปลี่ยน Code เล็กน้อยโดยตั้งใจ เช่น

>
เปลี่ยนเป็น
>=

แล้วดูว่า Test จับได้หรือไม่

ถ้า Mutated Code ยังทำ Test ผ่าน อาจแปลว่า Test ไม่ครอบคลุม Behavior นั้น

Gemini สามารถช่วยอธิบาย Mutation Candidate ได้ แต่การ Run ควรใช้ Tool ที่เหมาะสมใน Project

🚫 อย่า Generate Test จำนวนมากโดยไม่ Review

Test 500 ตัวไม่ได้แปลว่าดีกว่า Test 50 ตัว

ถ้า 500 Test

• ซ้ำ
• ช้า
• Brittle
• Test Implementation
• Assertion อ่อน

จะเพิ่ม Maintenance Cost

Quality สำคัญกว่า Quantity

📋 Checklist Unit Test ที่ดี

✅ ชัดเจน

รู้ว่า Test อะไร

✅ Deterministic

Run ซ้ำได้ผลเดียวกัน

✅ Independent

ไม่พึ่ง Test อื่น

✅ Fast

เหมาะกับการ Run บ่อย

✅ Relevant

ตรวจ Behavior ที่สำคัญ

✅ Readable

Developer อ่านรู้เรื่อง

✅ Good Assertion

จับ Bug ได้จริง

✅ Controlled Dependencies

Mock เฉพาะที่จำเป็น

✅ Edge Cases

ครอบคลุมความเสี่ยง

✅ Maintainable

ไม่ผูก Implementation มากเกินไป

🚫 10 ข้อผิดพลาดเมื่อให้ Gemini เขียน Unit Test

❶ ไม่บอก Framework

AI อาจเลือกผิด

❷ ไม่ให้ Requirement

Test อาจล็อก Bug เดิมไว้

❸ ไม่อ่าน Existing Test

Style ไม่เข้ากับ Project

❹ Mock ทุกอย่าง

Test ไม่มีความหมาย

❺ Test Implementation Detail

Refactor แล้ว Test พังโดยไม่จำเป็น

❻ มุ่ง Coverage 100%

ได้ Test ปริมาณมากแต่คุณภาพต่ำ

❼ แก้ Assertion ให้ Test ผ่าน

ซ่อน Bug จริง

❽ ไม่ Test Boundary

พลาดจุดที่ Bug เกิดบ่อย

❾ ไม่ Run Test จริง

Generate สำเร็จไม่ได้แปลว่า Test ผ่าน

❿ เชื่อ Gemini 100%

Test Code เองก็อาจผิดได้

🪜 Workflow ให้ Gemini เขียน Unit Test อัตโนมัติ

แนวทางที่แนะนำคือ

❶ ระบุ Framework

ใช้ของ Project เดิม

❷ ส่ง Source Code

Function/Class ที่ต้อง Test

❸ ส่ง Requirement

Expected Behavior

❹ อ่าน Existing Tests

ยึด Style เดิม

❺ สร้าง Test Cases

ยังไม่เขียน Code

❻ แบ่ง Normal/Boundary/Error

ตรวจ Case ให้ครบ

❼ Generate Test Code

ตาม Framework

❽ Review Mock

ใช้เฉพาะที่จำเป็น

❾ Run Test

ใน Environment จริง

❿ วิเคราะห์ Failure

อย่ารีบแก้ Assertion

⓫ Fix Code หรือ Test

ตาม Root Cause

⓬ Run Related Tests

ตรวจ Regression

⓭ Run Full Suite

ก่อน Merge

⓮ ตรวจ Coverage

ใช้เป็น Signal

⓯ Review Test Quality

ไม่ดูเพียงจำนวน Test

สำหรับ Code ที่ใช้บน comsiam Workflow นี้เหมาะกว่าการให้ Gemini Generate Test ทั้ง Project ในครั้งเดียว เพราะสามารถตรวจได้ว่าแต่ละ Test กำลังป้องกัน Bug หรือ Business Rule อะไรจริง ๆ

💡 10 Prompt ให้ Gemini เขียน Unit Test

❶ หา Test Case

“อ่าน Function นี้แล้วสร้าง Test Case ก่อน โดยยังไม่เขียน Test Code”

❷ Boundary

“ค้นหา Condition และ Boundary ทั้งหมด แล้วสร้าง Case ก่อนและหลังค่าขอบเขต”

❸ Existing Style

“อ่าน Test File นี้แล้วสร้าง Test ใหม่ตาม Naming, Fixture และ Assertion Pattern เดิม”

❹ Python

“สร้าง pytest สำหรับ Function นี้โดยไม่เพิ่ม Dependency ใหม่”

❺ JavaScript

“ตรวจ package.json แล้วใช้ Test Framework ที่ Project มีอยู่ ห้ามเดา Framework”

❻ PHP

“สร้าง PHPUnit Test ตาม Namespace และ Autoload ของ Project เดิม”

❼ Mock

“ระบุ Dependency ที่ต้อง Mock และอธิบายว่าทำไมก่อนสร้าง Mock”

❽ Regression

“สร้าง Test ที่ Fail กับ Bug ปัจจุบันและ Pass หลังแก้ Root Cause”

❾ Test Failure

“วิเคราะห์ว่า Test Fail เพราะ Production Code, Test Code, Mock หรือ Requirement ก่อนแก้อะไรก็ตาม”

❿ Review

“Review Test Suite นี้ด้าน Over-mocking, Flaky Test, Weak Assertion และ Duplicate Setup”

❓ คำถามที่พบบ่อย

Gemini เขียน Unit Test ได้ไหม

ได้ Gemini สามารถช่วยวิเคราะห์ Code สร้าง Test Case และ Generate Unit Test Code ตามภาษาและ Test Framework ที่กำหนด

Gemini รัน Unit Test ให้อัตโนมัติไหม

การ Generate Test กับการ Run Test เป็นคนละขั้นกัน ใน Project จริงควรนำ Test ไป Run ด้วย Test Runner และ Environment ของ Project เพื่อยืนยันว่า Test Compile/Execute และผ่านจริง

ควรบอก Test Framework ให้ Gemini ไหม

ควรอย่างมาก โดยเฉพาะ Project ที่มี Framework อยู่แล้ว เพราะ Syntax, Fixture และ Mock API แตกต่างกัน

Gemini สร้าง Regression Test ได้ไหม

ได้ และเป็นหนึ่งใน Use Case ที่มีประโยชน์มาก โดยควรสร้าง Test ที่ Reproduce Bug และ Fail ก่อนแก้ จากนั้นต้อง Pass หลัง Root Cause ถูกแก้

Coverage สูงหมายความว่า Test ดีไหม

ไม่เสมอ Coverage บอกว่า Code ส่วนใดถูก Execute แต่ไม่ได้ยืนยันว่า Assertion มีคุณภาพหรือ Business Rule สำคัญถูกตรวจครบ

Unit Test จาก Gemini เชื่อถือได้ 100% หรือไม่

ไม่ควรถือว่าถูกต้อง 100% Test Code สามารถมี Bug หรือ Assertion ผิดได้ ต้อง Review และ Run จริงเช่นเดียวกับ Production Code

🎯 สรุป

วิธีให้ Gemini เขียน Unit Test อัตโนมัติที่ได้ผลดีที่สุดไม่ใช่การสั่งให้ Generate Test จำนวนมากทันที แต่ควรเริ่มจาก Requirement → Source Code → Existing Test Style → Test Cases → Unit Test Code → Run → Review

Gemini สามารถช่วยหา Normal Case, Boundary Case, Invalid Input, Error Case และ Regression Case ได้ รวมถึงช่วยเขียน Test สำหรับ Framework ต่าง ๆ แต่ต้องระบุ Framework และ Version ของ Project ให้ชัดเพื่อป้องกัน Test Code ที่ไม่เข้ากับ Environment

สิ่งสำคัญคือ Test ต้องตรวจ Behavior ที่ถูกต้องตาม Requirement ไม่ใช่เพียงล็อก Behavior ของ Code ปัจจุบัน เพราะถ้า Production Code มี Bug แล้วให้ Geminiสร้าง Test จาก Code อย่างเดียว AI อาจสร้าง Test ที่ยืนยัน Bug นั้นแทนที่จะจับ Bug

หลัง Generate Test ต้อง Run ด้วย Test Runner จริง ตรวจ Failure และ Run Full Test Suite ก่อน Merge ทุกครั้ง Google เองก็แนะนำให้ Review และ Test Code ที่ Generative AI ช่วยสร้างอย่างระมัดระวังเพื่อค้นหา Error, Bug และ Vulnerability

แนวทางของ comsiam คือใช้ Gemini ช่วยลดเวลาออกแบบ Test Case และเขียน Boilerplate ส่วนคุณภาพของ Unit Test ยังต้องถูกพิสูจน์ด้วย Requirement, Runtime และความสามารถในการจับ Regression จริง