tdd

Tổng quan về skill tdd

tdd là một hướng dẫn chuyên biệt cho phát triển theo kiểu test-first với vòng lặp red-green-refactor chặt chẽ, chứ không phải một prompt chung chung kiểu “viết vài test đi”. Skill này phù hợp nhất với developer muốn dùng AI để xây tính năng hoặc sửa bug nhưng vẫn giữ test bám vào hành vi qua public interface thay vì chi tiết cài đặt bên trong.

tdd dùng để làm gì

Hãy dùng tdd for Test Driven Development khi bạn muốn model:

• chia tính năng thành các lát dọc nhỏ
• viết từng test fail một
• chỉ cài đặt đúng lượng code tối thiểu để test pass
• refactor an toàn sau khi đã xanh
• tránh những test mong manh dễ vỡ khi refactor vô hại

Ai sẽ nhận được nhiều giá trị nhất từ tdd

tdd skill phù hợp nhất nếu bạn đã có:

• một codebase có thể chạy test được
• một public API, endpoint, command hoặc luồng người dùng rõ ràng để nhắm tới
• quyền thay đổi cả test lẫn production code
• mong muốn ưu tiên test kiểu integration hơn là mock dày đặc

Skill này đặc biệt hữu ích cho backend service, library, domain logic và các application flow nơi hành vi có thể được kiểm chứng qua một interface thật.

Điều gì khiến skill tdd này khác biệt

Điểm khác biệt lớn nhất là quan điểm rất rõ ràng về chất lượng test:

• test hành vi, không test nội bộ
• ưu tiên test kiểu integration
• chỉ mock ở ranh giới hệ thống
• tránh “horizontal slicing”, tức viết hết test trước rồi mới viết hết code sau
• dùng TDD để định hình interface tốt hơn, không chỉ để tăng coverage

Vì vậy, cách dùng tdd usage ở đây kỷ luật hơn nhiều so với một prompt thông thường chỉ yêu cầu AI “viết test và implementation”.

Điều gì có thể cản trở việc áp dụng

Skill này sẽ kém phù hợp hơn nếu môi trường của bạn không chạy được test, codebase không có public seam ổn định, hoặc team chủ yếu muốn unit test nặng snapshot hay nặng mock. Nó cũng giả định rằng bạn sẵn sàng lặp theo từng bước nhỏ thay vì tạo cả tính năng trong một lần.

Cách dùng skill tdd

Cài đặt tdd trong môi trường skills của bạn

Nếu bạn đang dùng hệ thống Skills từ repository, một cách cài đặt phổ biến là:

npx skills add mattpocock/skills --skill tdd

Sau đó, hãy gọi tdd khi yêu cầu model triển khai hoặc sửa hành vi theo workflow test-first.

Hãy đọc các file này trước khi dùng tdd nhiều

Cách nhanh nhất để hiểu skill này là đọc theo thứ tự:

1. SKILL.md
2. tests.md
3. mocking.md
4. interface-design.md
5. refactoring.md
6. deep-modules.md

Thứ tự này rất quan trọng. SKILL.md giải thích triết lý vận hành, còn các file hỗ trợ sẽ cho bạn biết cụ thể thế nào là “test tốt” và “thiết kế tốt” trong thực tế.

Nắm rõ workflow cốt lõi mà tdd mong đợi

Skill này được xây quanh một vòng lặp chặt:

1. chọn một hành vi nhỏ
2. viết một test fail qua public interface
3. cài đặt lượng code tối thiểu để pass
4. refactor nhưng vẫn giữ test xanh
5. lặp lại với lát nhỏ tiếp theo

Nếu bạn yêu cầu làm cả tính năng trong một lần, bạn sẽ mất đi phần lớn giá trị của tdd usage.

Bắt đầu từ hành vi, không phải từ ý tưởng implementation

Input tốt:

• “Add checkout support for expired cards. Public entrypoint is checkout(cart, paymentMethod). Existing test file is checkout.test.ts. Keep using integration-style tests.”

Input yếu:

• “Create classes for payment orchestration and add unit tests for each method.”

Prompt đầu tiên cho skill một mục tiêu ở mức hành vi. Prompt thứ hai lại đẩy nó sang suy đoán thiết kế nội bộ và tạo ra các test dễ gãy.

Cung cấp public interface và lệnh chạy test cho skill

Để tdd install và quá trình thực thi cho ra kết quả tốt, hãy nêu rõ:

• function, route, CLI command hoặc UI action đang được test
• test nằm ở đâu
• test runner và lệnh chạy
• các ràng buộc liên quan như DB, HTTP hoặc dịch vụ bên ngoài
• phần nào được phép mock và phần nào không

Một mẫu prompt thực dụng:

Use the tdd skill.

Goal: Add [behavior].
Public interface: [function/route/command].
Test location: [path].
Run tests with: [command].
Boundaries to mock: [external API, clock, filesystem].
Do not mock: [internal modules/classes].
Work in red-green-refactor steps and explain each step briefly.

Dùng lát dọc, đừng dùng lát ngang

Một trong những bài học thực tế quan trọng nhất từ repository này là tránh viết ồ ạt toàn bộ test ngay từ đầu. Dùng tdd usage đúng cách ở đây có nghĩa là:

• chọn một kịch bản thật
• làm cho nó pass
• để kết quả đó định hướng kịch bản tiếp theo

Cách này giảm các abstraction do tưởng tượng ra và thường cho ra API shape tốt hơn.

Ưu tiên test kiểu integration trong tdd

Repository này nghiêng mạnh về các test chạy qua code path thật thông qua public API. Trong thực tế, điều đó có nghĩa là:

• gọi exported function thay vì helper private
• đi vào route handler qua interface được hỗ trợ của nó
• xác minh kết quả quan sát được, không kiểm tra thứ tự gọi nội bộ
• đặt tên test theo năng lực/hành vi, chẳng hạn “user can checkout with valid cart”

Nếu một lần refactor thay đổi nội bộ nhưng hành vi vẫn giữ nguyên, một test tốt thông thường vẫn nên xanh.

Chỉ mock ở ranh giới hệ thống

tdd skill không chống mock; nó chống việc mock chính implementation của bạn. Hãy mock:

• payment gateway
• email provider
• time/randomness
• đôi khi là database hoặc filesystem, tùy cách setup test

Đừng mock:

• module do chính bạn viết
• các internal collaborator
• private method
• các thin wrapper mà bạn kiểm soát

Chỉ riêng nguyên tắc này thôi cũng có thể cải thiện chất lượng đầu ra nhiều hơn hầu hết các kiểu chỉnh prompt khác.

Định hình code để dễ test trước khi viết quá nhiều code

Các file hỗ trợ nhấn mạnh một điểm quan trọng: interface tốt hơn sẽ làm TDD dễ hơn. Hãy yêu cầu model ưu tiên kiểu code:

• nhận dependency từ bên ngoài thay vì tự khởi tạo bên trong
• trả về kết quả thay vì âm thầm mutate hidden state
• giữ public surface area ở mức nhỏ

Nếu thiết kế hiện tại khiến việc test trở nên khó khăn, hãy bảo model trước tiên đề xuất một public interface nhỏ hơn và dễ test hơn.

Một ví dụ prompt tdd mạnh

Use the tdd skill to add password reset token expiry.

Context:
- Node + TypeScript
- Public API: `requestPasswordReset(email)` and `resetPassword(token, newPassword)`
- Tests: `src/auth/password-reset.test.ts`
- Run with: `pnpm test password-reset`
- Mock only email sending and time
- Do not mock repository code or internal services

Please:
1. choose the smallest failing behavior first
2. write integration-style tests through public APIs
3. implement minimum code to pass
4. refactor after green
5. avoid asserting internal call counts unless at an external boundary

Ví dụ này hiệu quả vì nó cho skill một mục tiêu rõ ràng, chính sách boundary cụ thể và một đường chạy thực tế.

Theo dõi các dấu hiệu chính của chất lượng đầu ra tdd

Một kết quả tdd guide tốt từ skill này thường có:

• test được đặt tên theo hành vi mà người dùng nhìn thấy
• mỗi lần chỉ xử lý một kịch bản nhỏ
• implementation tối thiểu cho từng bước
• ghi chú refactor sau khi đã xanh
• rất ít hoặc không bị buộc chặt vào cấu trúc private

Một kết quả kém thường có:

• quá nhiều mock cho code nội bộ
• assertion về thứ tự gọi
• bộ test quá lớn ngay ở bước đầu
• abstraction được dựng lên trước khi có bất kỳ hành vi nào pass

Câu hỏi thường gặp về skill tdd

tdd chỉ dành cho tính năng hoàn toàn mới thôi sao?

Không. tdd skill cũng rất hợp để sửa bug. Trong nhiều codebase trưởng thành, bước đầu tốt nhất thường là viết một regression test đang fail để tái hiện bug qua public interface, sau đó áp dụng bản sửa tối thiểu, rồi mới dọn dẹp.

Skill tdd này có thân thiện với người mới không?

Có, nếu bạn đã hiểu cách chạy test của dự án mình. Hướng dẫn này có quan điểm rõ ràng nhưng khá đơn giản: test hành vi, giữ lát cắt nhỏ và tránh assertion vào chi tiết implementation. Tuy vậy, người mới hoàn toàn vẫn có thể cần hỗ trợ thêm để hiểu kiến trúc dự án và bộ công cụ test.

tdd khác gì với việc chỉ bảo AI viết test?

Prompt thông thường thường tạo ra test thiên về coverage hoặc nặng mock. tdd skill sẽ đẩy model theo hướng:

• đặc tả hành vi
• refactor an toàn hơn
• interface sạch hơn
• các bước lặp nhỏ hơn

Điều đó làm thay đổi cả test lẫn thiết kế production.

Khi nào tôi không nên dùng tdd?

Hãy bỏ qua hoặc giới hạn tdd for Test Driven Development khi:

• hành vi đó chưa thể được kiểm chứng một cách có ý nghĩa
• môi trường quá khó chạy trong quá trình lặp
• bạn đang làm exploratory throwaway spike
• tác vụ chủ yếu mang tính cơ học, như đổi tên hoặc nâng version dependency

Bạn vẫn có thể quay lại TDD khi public seam đã rõ hơn.

tdd có bắt buộc chỉ dùng integration test không?

Không hẳn, nhưng thiên hướng của nó là test kiểu integration qua interface thật. Mục tiêu không phải là tạo test to nhất có thể; mục tiêu là test hành vi tại một seam ổn định. Các test nhỏ, tập trung vẫn hoàn toàn ổn nếu chúng bám vào public interface và tránh ghép chặt với nội bộ.

Những ngôn ngữ hay framework nào phù hợp với skill này?

Các ý tưởng ở đây khá độc lập với ngôn ngữ. Ví dụ có thiên về TypeScript và JavaScript, nhưng các nguyên tắc thiết kế này cũng áp dụng tốt cho Python, Java, Go, Ruby và những hệ sinh thái tương tự, miễn là bạn có thể xác định public interface rõ ràng và ranh giới để test.

Cách cải thiện skill tdd

Cho tdd một lát cắt đầu tiên nhỏ hơn

Cách dễ nhất để cải thiện kết quả từ tdd là thu nhỏ bước đầu tiên. Thay vì “build user invitations”, hãy bắt đầu bằng “user with valid email can request an invitation”. Lát cắt nhỏ hơn sẽ giảm việc bịa ra kiến trúc và tạo ra các test sạch hơn.

Đưa ra quy tắc boundary thật rõ ràng

Nhiều đầu ra tệ bắt nguồn từ chính sách mock không rõ. Hãy nói với model thật cụ thể:

• hệ thống bên ngoài nào có thể mock
• module nội bộ nào phải giữ nguyên là thật
• có test DB hay không
• thời gian nên được inject hay freeze

Điều này giúp skill bám đúng triết lý của repository.

Yêu cầu tên test theo public interface

Nếu bạn muốn test tốt hơn, hãy yêu cầu tên test mô tả kết quả:

• tốt: user can checkout with valid cart
• yếu hơn: checkout calls payment service

Chỉ một chỉ dẫn này thôi thường đã đủ để ngăn test trôi dần sang chi tiết implementation.

Buộc vòng lặp red-green-refactor phải hiện rõ

Nếu câu trả lời đầu tiên quay về dưới dạng một cục implementation hoàn chỉnh, hãy yêu cầu model tổ chức lại:

• hiển thị test fail đầu tiên
• hiển thị code tối thiểu để pass
• giải thích phần refactor tách riêng
• nếu cần thì dừng lại sau một lát cắt

tdd skill hoạt động tốt nhất khi vòng lặp được thể hiện rõ ràng, không phải chỉ ngầm hiểu.

Cải thiện thiết kế khi việc viết test trở nên gượng ép

Nếu model gặp khó khi viết test sạch, vấn đề thường nằm ở thiết kế interface chứ không phải cú pháp test. Hãy yêu cầu nó chỉnh lại theo hướng:

• dependency injection
• input và output tường minh
• public surface nhỏ hơn
• ít side effect hơn

Đây là lúc interface-design.md và deep-modules.md trở nên đặc biệt hữu ích.

Dùng refactor như một vòng kiểm chất lượng riêng

Sau vài lát cắt đã xanh, hãy chủ động yêu cầu một lượt review refactor dựa trên các tín hiệu từ repository:

• duplication
• long methods
• shallow modules
• feature envy
• primitive obsession

Cách này giúp tdd usage không dừng ở mức “test pass là xong” mà còn cải thiện khả năng bảo trì mà không làm thay đổi hành vi.

Sửa sớm các kiểu lỗi phổ biến

Nếu chất lượng đầu ra giảm, đây thường là các nguyên nhân quen thuộc:

• tạo quá nhiều code trước test fail đầu tiên
• mock internal collaborator quá nặng
• test kiểm tra chi tiết implementation
• yêu cầu tính năng quá lớn cho một chu kỳ
• public interface không rõ hoặc thay đổi ở mọi bước

Khi gặp tình huống đó, hãy reset lại với một hành vi, một seam, một test fail.

Dùng các file trong repository như công cụ ra quyết định

Để có kết quả tốt hơn, hãy đối chiếu vấn đề của bạn với đúng tài liệu hỗ trợ:

• tests.md khi style test còn yếu
• mocking.md khi quyết định boundary chưa rõ
• interface-design.md khi seam còn gượng
• refactoring.md sau khi đã xanh
• deep-modules.md khi API shape bắt đầu quá rộng

Lộ trình đọc này mang lại nhiều giá trị hơn so với chỉ lướt qua SKILL.md.

Lặp lại bằng cách siết chặt ràng buộc, không phải lặp nguyên prompt cũ

Nếu đầu ra đầu tiên chỉ ở mức trung bình, đừng chỉ nói “try again.” Hãy cải thiện vòng tiếp theo bằng các ràng buộc cụ thể:

• chỉ nhắm vào một hành vi
• giữ nguyên public API hiện tại
• không mock module nội bộ
• ưu tiên test DB hơn repository mock
• dừng sau chu kỳ red-green-refactor đầu tiên

Kiểu lặp này cải thiện chất lượng tdd guide ổn định hơn nhiều so với việc chỉ yêu cầu thêm chi tiết.