{/* Trang này được tạo tự động từ SKILL.md của kỹ năng bởi website/scripts/generate-skill-docs.py. Chỉnh sửa nguồn SKILL.md, không phải trang này. */}

Phát triển dựa trên thử nghiệm

TDD: thực thi RED-GREEN-REFACTOR, kiểm tra trước khi viết mã.

Siêu dữ liệu kỹ năng

Nguồn	Đi kèm (được cài đặt theo mặc định)
Đường dẫn

skills/software-development/test-driven-development ` | | Phiên bản |

1.1.0 ` | | Tác giả | Đặc vụ Hermes (chuyển thể từ obra/siêu năng lực) | | Giấy phép | MIT | | Nền tảng | Linux, macOS, Windows | | Thẻ |

testing

, `tdd

, `development

, `quality

, red-green-refactor | | Kỹ năng liên quan | XPROTECTX17XPROTECTX, XPROTECTX18XPROTECTX, XPROTECTX19XPROTECTX |

Tham khảo: đầy đủ SKILL.md

thông tin

Sau đây là định nghĩa kỹ năng đầy đủ mà Hermes tải khi kỹ năng này được kích hoạt. Đây là những gì tác nhân coi là hướng dẫn khi kỹ năng được kích hoạt.

Phát triển dựa trên thử nghiệm (TDD)

Tổng quan

Viết bài kiểm tra đầu tiên. Hãy xem nó thất bại. Viết mã tối thiểu để vượt qua.

Nguyên tắc cốt lõi: Nếu không xem thử nghiệm thất bại, bạn không biết liệu thử nghiệm đó có đúng hay không.

Vi phạm nội dung chính là vi phạm tinh thần của nội quy.

Khi nào nên sử dụng`Luôn luôn:

• Tính năng mới
• Sửa lỗi
• Tái cấu trúc
• Thay đổi hành vi`Ngoại lệ (hãy hỏi người dùng trước):
• Nguyên mẫu vứt đi
• Mã được tạo
• Tập tin cấu hình

Bạn đang nghĩ "bỏ qua TDD chỉ lần này thôi"? Dừng lại. Đó là sự hợp lý hóa.

Luật Sắt

` NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

` ``Viết mã trước khi kiểm tra? Xóa nó. Bắt đầu lại.

Không có ngoại lệ:

• Đừng giữ nó làm "tài liệu tham khảo"
• Đừng “thích ứng” nó khi viết bài test
• Đừng nhìn vào nó
• Xóa có nghĩa là xóa

Thực hiện mới từ các thử nghiệm. Giai đoạn.

Chu trình tái cấu trúc đỏ-xanh

ĐỎ — Viết bài kiểm tra thất bại

Viết một bài kiểm tra tối thiểu cho thấy điều gì sẽ xảy ra.

Bài kiểm tra tốt:

`

def test_retries_failed_operations_3_times():
    attempts = 0
    def operation():
        nonlocal attempts
        attempts += 1
        if attempts < 3:
            raise Exception('fail')
        return 'success'`result = retry_operation(operation)

assert result == 'success'
    assert attempts == 3

`

Xóa tên, kiểm tra hành vi thực tế, một điều.

**Bài kiểm tra tồi:**

`
`Python
def test_retry_works():
    mock = MagicMock()
    mock.side_effect = [Exception(), Exception(), 'success']
    result = retry_operation(mock)
    assert result == 'success'  # What about retry count? Timing?

`

Tên mơ hồ, test thử không phải code thật.

**Yêu cầu:**

- Một hành vi cho mỗi bài kiểm tra
- Xóa tên mô tả ("và" trong tên? Tách nó ra)
- Mã thật, không phải mã giả (trừ khi thực sự không thể tránh khỏi)
- Tên mô tả hành vi, không thực hiện

### Xác minh ĐỎ — Xem nó thất bại`**BẮT BUỘC. Không bao giờ bỏ qua.**

``` bash

# Use terminal tool to run the specific test
pytest tests/test_feature.py::test_specific_behavior -v

`
``Xác nhận:
- Kiểm tra không thành công (không phải lỗi chính tả)
- Thông báo lỗi được mong đợi
- Thất bại vì thiếu tính năng`**Bài kiểm tra thành công ngay lập tức?** Bạn đang kiểm tra hành vi hiện có. Sửa bài kiểm tra.

**Kiểm tra lỗi?** Sửa lỗi, chạy lại cho đến khi lỗi chính xác.

### XANH — Mã tối thiểu

Viết mã đơn giản nhất để vượt qua bài kiểm tra. Không còn gì nữa.

**Tốt:**

`
``` python
def add(a, b):
    return a + b  # Nothing extra

`
``**Xấu:**

`
`Python
def add(a, b):
    result = a + b
    logging.info(f"Adding \{a} + \{b} = \{result}")  # Extra!
    return result

`
``Không thêm các tính năng, cấu trúc lại mã khác hoặc "cải thiện" ngoài quá trình kiểm tra.

**Gian lận được chấp nhận trong màu XANH:**

- Giá trị trả về mã cứng
- Sao chép-dán
- Mã trùng lặp
- Bỏ qua các trường hợp cạnh

Chúng tôi sẽ sửa nó trong REFACTOR.

### Xác minh XANH — Xem nó vượt qua`**BẮT BUỘC.**

``` bash

# Run the specific test
pytest tests/test_feature.py::test_specific_behavior -v

# Then run ALL tests to check for regressions
pytest tests/ -q

`
``Xác nhận:
- Vượt qua bài kiểm tra
- Các bài kiểm tra khác vẫn đạt
- Đầu ra nguyên vẹn (không có lỗi, cảnh báo)

**Thử nghiệm thất bại?** Sửa mã chứ không phải sửa thử.

**Các thử nghiệm khác không thành công?** Hãy khắc phục hồi quy ngay bây giờ.

### CÔNG CỤ TÁC GIẢ — Dọn dẹp

Chỉ sau màu xanh lá cây:
- Loại bỏ trùng lặp
- Cải thiện tên
- Trích xuất người trợ giúp
- Rút gọn biểu thức

Giữ cho các bài kiểm tra luôn xanh trong suốt. Đừng thêm hành vi.

**Nếu kiểm tra thất bại trong quá trình tái cấu trúc:** Hoàn tác ngay lập tức. Thực hiện các bước nhỏ hơn.

### Lặp lại

Kiểm tra thất bại tiếp theo cho hành vi tiếp theo. Một chu kỳ tại một thời điểm.

## Tại sao đơn hàng lại quan trọng`**"Tôi sẽ viết bài kiểm tra sau để xác minh nó hoạt động"**

Các bài kiểm tra được viết sau mã sẽ vượt qua ngay lập tức. Vượt qua ngay lập tức chứng tỏ không có gì:
- Có thể kiểm tra sai
- Có thể kiểm tra việc triển khai chứ không phải hành vi
- Có thể lỡ trường hợp bạn quên
- Bạn chưa bao giờ thấy nó bắt được con bọ

Thử nghiệm đầu tiên buộc bạn phải thấy thử nghiệm thất bại, chứng tỏ nó thực sự đang thử nghiệm điều gì đó.

**"Tôi đã kiểm tra thủ công tất cả các trường hợp đặc biệt"**

Kiểm tra thủ công là đặc biệt. Bạn nghĩ rằng bạn đã thử nghiệm mọi thứ nhưng:
- Không có hồ sơ về những gì bạn đã thử nghiệm
- Không thể chạy lại khi code thay đổi
- Dễ quên các trường hợp dưới áp lực
- "Nó có tác dụng khi tôi thử" ≠ toàn diện

Kiểm tra tự động là có hệ thống. Họ chạy theo cùng một cách mọi lúc.

**"Xóa X giờ làm việc là lãng phí"**

Ngụy biện chi phí chìm. Thời gian đã qua rồi. Sự lựa chọn của bạn bây giờ:
- Xóa và viết lại bằng TDD (độ tin cậy cao)
- Giữ nó và thêm các bài kiểm tra sau (độ tin cậy thấp, có thể có lỗi)`"Lãng phí" là giữ mã mà bạn không thể tin tưởng.

**"TDD là giáo điều, thực dụng có nghĩa là thích nghi"**TDD LÀ thực dụng:
- Tìm lỗi trước khi commit (nhanh hơn debug sau)
- Ngăn chặn hồi quy (kiểm tra bắt lỗi ngay lập tức)
- Hành vi của tài liệu (kiểm tra cho thấy cách sử dụng mã)
- Cho phép tái cấu trúc (thay đổi tự do, kiểm tra các điểm ngắt)

Phím tắt "thực dụng" = gỡ lỗi trong quá trình sản xuất = chậm hơn.

**"Kiểm tra sau khi đạt được mục tiêu tương tự — đó là tinh thần chứ không phải nghi lễ"**

Không. Câu trả lời kiểm tra sau "Cái này dùng để làm gì?" Kiểm tra câu trả lời đầu tiên "Việc này nên làm gì?"

Kiểm tra sau bị sai lệch bởi việc triển khai của bạn. Bạn kiểm tra những gì bạn đã xây dựng, không phải những gì được yêu cầu. Thử nghiệm phát hiện trường hợp cạnh bắt buộc đầu tiên trước khi triển khai.

## Những cách hợp lý hóa phổ biến

| Xin lỗi | Thực tế |
|--------|----------|
| "Quá đơn giản để kiểm tra" | Phá mã đơn giản. Kiểm tra mất 30 giây. |
| "Tôi sẽ kiểm tra sau" | Các bài kiểm tra trôi qua ngay lập tức không chứng minh được gì. |
| "Kiểm tra sau khi đạt được mục tiêu tương tự" | Tests-after = "cái này dùng để làm gì?" Tests-first = "việc này nên làm gì?" |
| "Đã được kiểm tra thủ công" | Đặc biệt ≠ có hệ thống. Không có bản ghi, không thể chạy lại. |
| "Xóa X giờ là lãng phí" | Ngụy biện chi phí chìm. Giữ mã chưa được xác minh là nợ kỹ thuật. |
| "Giữ làm tài liệu tham khảo, viết bài kiểm tra trước" | Bạn sẽ thích nghi với nó. Đó là thử nghiệm sau. Xóa có nghĩa là xóa. |
| “Cần khám phá trước” | Khỏe. Vứt bỏ việc khám phá, bắt đầu với TDD. |
| "Thử nghiệm chăm chỉ = thiết kế không rõ ràng" | Nghe bài kiểm tra. Khó kiểm tra = khó sử dụng. |
| "TDD sẽ làm tôi chậm lại" | TDD nhanh hơn việc gỡ lỗi. Thực dụng = thử nghiệm trước tiên. |
| "Kiểm tra thủ công nhanh hơn" | Hướng dẫn sử dụng không chứng minh được các trường hợp khó khăn. Bạn sẽ kiểm tra lại mọi thay đổi. |
| "Mã hiện tại không có kiểm tra" | Bạn đang cải thiện nó. Thêm các bài kiểm tra cho mã bạn chạm vào. |

## Cờ đỏ - DỪNG và bắt đầu lại

Nếu bạn thấy mình đang thực hiện bất kỳ thao tác nào trong số này, hãy xóa mã và khởi động lại bằng TDD:
- Mã trước khi kiểm tra
- Kiểm tra sau khi thực hiện
- Kiểm tra thành công ngay trong lần chạy đầu tiên
- Không thể giải thích tại sao bài kiểm tra thất bại
- Các bài kiểm tra được thêm vào "sau"
- Hợp lý hóa “chỉ lần này thôi”
- "Tôi đã kiểm tra thủ công rồi"
- "Kiểm tra sau khi đạt được mục đích tương tự"
- "Giữ làm tài liệu tham khảo" hoặc "điều chỉnh mã hiện có"
- "Đã tốn X giờ rồi, xóa thật lãng phí"
- "TDD giáo điều, tôi thực dụng"
- "Chuyện này khác vì..."`**Tất cả những điều này có nghĩa là: Xóa mã. Bắt đầu lại với TDD.**

## Danh sách kiểm tra xác minh

Trước khi đánh dấu công việc đã hoàn thành:
- [ ] Mỗi hàm/phương thức mới đều có một bài kiểm tra
- [ ] Đã chứng kiến từng thử nghiệm thất bại trước khi triển khai
- [ ] Mỗi lần kiểm tra đều thất bại vì lý do dự kiến (thiếu tính năng, không phải lỗi đánh máy)
- [ ] Viết mã tối thiểu để vượt qua mỗi bài kiểm tra
- [ ] Tất cả các bài kiểm tra đều vượt qua
- [ ] Đầu ra nguyên sơ (không có lỗi, cảnh báo)
- [ ] Các thử nghiệm sử dụng mã thực (chỉ mô phỏng nếu không thể tránh khỏi)
- [] Các trường hợp cạnh và lỗi được bảo hiểm

Không thể chọn tất cả các hộp? Bạn đã bỏ qua TDD. Bắt đầu lại.

## Khi bị mắc kẹt

| Vấn đề | Giải pháp |
|----------|----------|
| Không biết cách kiểm tra | Viết API mong muốn. Viết khẳng định đầu tiên. Hỏi người dùng. |
| Kiểm tra quá phức tạp | Thiết kế quá phức tạp. Đơn giản hóa giao diện. |
| Phải chế giễu mọi thứ | Mã quá ghép. Sử dụng tính năng tiêm phụ thuộc. |
| Thiết lập thử nghiệm rất lớn | Trích xuất người trợ giúp. Vẫn còn phức tạp? Đơn giản hóa thiết kế. |

## Tích hợp đại lý Hermes

### Đang chạy thử nghiệm

Sử dụng công cụ 
`terminal
` để chạy thử nghiệm ở từng bước:

``` python

# RED — verify failure
terminal("pytest tests/test_feature.py::test_name -v")

# GREEN — verify pass
terminal("pytest tests/test_feature.py::test_name -v")

# Full suite — verify no regressions
terminal("pytest tests/ -q")

`

### Với delegate_task

Khi cử các đại lý con đi triển khai, hãy thực thi TDD trong mục tiêu:

``` python
delegate_task(
    goal="Implement [feature] using strict TDD",
    context="""
    Follow test-driven-development skill:

    1. Write failing test FIRST
    2. Run test to verify it fails
    3. Write minimal code to pass
    4. Run test to verify it passes
    5. Refactor if needed
    6. Commit

Project test command: pytest tests/ -q
    Project structure: [describe relevant files]
    """,
    toolsets=['terminal', 'file']
)

`

### Với tính năng gỡ lỗi hệ thống

Đã tìm thấy lỗi? Viết bài kiểm tra thất bại tái tạo nó. Thực hiện theo chu kỳ TDD. Thử nghiệm chứng minh sự khắc phục và ngăn chặn sự hồi quy.

Không bao giờ sửa lỗi mà không kiểm tra.

## Kiểm tra các mẫu chống
- **Thử nghiệm hành vi mô phỏng thay vì hành vi thực** — mô phỏng nên xác minh các tương tác, không thay thế hệ thống đang được thử nghiệm
- **Chi tiết triển khai thử nghiệm** — hành vi/kết quả thử nghiệm, không phải lệnh gọi phương thức nội bộ
- **Chỉ đường dẫn hạnh phúc** — luôn kiểm tra các trường hợp biên, lỗi và ranh giới
- **Thử nghiệm giòn** — các thử nghiệm phải xác minh hành vi chứ không phải cấu trúc; tái cấu trúc không nên phá vỡ chúng

## Quy tắc cuối cùng

`
Production code → test exists and failed first
Otherwise → not TDD

`
``Không có ngoại lệ nếu không có sự cho phép rõ ràng của người dùng.