test-driven-development

Tổng quan về skill test-driven-development

Skill test-driven-development thực sự làm gì

Skill test-driven-development cung cấp cho AI agent một quy trình TDD chặt chẽ khi làm tính năng mới, sửa lỗi và thay đổi hành vi: viết test trước, xác nhận test fail vì đúng lý do, viết lượng code production tối thiểu để pass, rồi refactor một cách an toàn. Giá trị cốt lõi của skill này không phải là “tiện thể viết thêm test”, mà là ép đúng thứ tự thực hiện để phần triển khai được dẫn dắt bởi hành vi có thể kiểm chứng bằng test.

Skill này phù hợp nhất với ai

test-driven-development skill đặc biệt phù hợp với developer dùng AI để làm việc trực tiếp trên repository thật, nơi tính đúng đắn là yếu tố quan trọng: tính năng ứng dụng, logic dịch vụ, sửa bug, refactor và ngăn lỗi hồi quy. Skill này особенно hữu ích khi bạn muốn model ngừng lao thẳng vào phần implementation, thay vào đó tạo ra các bước nhỏ hơn, có thể kiểm tra và review rõ ràng.

Nhu cầu thực tế mà skill này giải quyết

Phần lớn người dùng cài test-driven-development vì các prompt code thông thường thường tạo code trước rồi mới “vá” test vào sau. Skill này thay đổi hẳn hành vi đó. Nó giúp bạn có được implementation bám chặt vào các test đang fail, nhờ vậy agent dễ review hơn và ít có xu hướng bịa ra hành vi chưa được kiểm chứng.

Điểm khác biệt so với prompt kiểu “viết test đi”

Điểm khác biệt nằm ở “iron law” của skill: không viết code production nếu chưa có một test fail trước. Đây là ràng buộc chặt hơn nhiều so với prompt thông thường. Skill cũng nhấn mạnh việc phải xác minh rằng lỗi fail ban đầu là đúng loại lỗi cần thấy, chứ không chỉ là bất kỳ trạng thái đỏ nào — một hàng rào an toàn rất thực tế mà nhiều bản tóm tắt TDD hời hợt thường bỏ qua.

Những giới hạn quan trọng cần biết trước khi cài

Đây là một skill về quy trình, không phải bộ công cụ test theo framework cụ thể. Nó sẽ không tự quyết toàn bộ kiến trúc test cho bạn, và cũng không đi kèm script hỗ trợ hay tài liệu tham chiếu sâu ngoài SKILL.md và testing-anti-patterns.md. Nếu bạn cần hướng dẫn thiết lập chi tiết cho Jest, Pytest, JUnit hoặc Playwright, skill này phù hợp hơn khi dùng như một lớp workflow, không phải một cẩm nang test đầy đủ.

Cách dùng skill test-driven-development

Cài skill test-driven-development

Cài từ repository bằng lệnh:

npx skills add https://github.com/obra/superpowers --skill test-driven-development

Nếu môi trường của bạn hỗ trợ local skill discovery, hãy xác nhận skill xuất hiện với tên test-driven-development và agent đã nhìn thấy nó trước khi bắt đầu làm tính năng.

Hãy đọc các file này trước

Với luồng test-driven-development install và sử dụng, hãy bắt đầu từ:

• skills/test-driven-development/SKILL.md
• skills/test-driven-development/testing-anti-patterns.md

Đọc SKILL.md trước để nắm workflow và các ràng buộc. Sau đó đọc testing-anti-patterns.md nếu tác vụ của bạn có dùng mocks, cần cô lập thành phần, làm UI test, hoặc có nguy cơ thêm các “test-only seam” vào code production.

Nắm rõ đầu vào tối thiểu mà skill cần

Skill hoạt động tốt nhất khi bạn cung cấp:

• tính năng, bug hoặc thay đổi hành vi cần làm
• các file liên quan hoặc ranh giới module
• framework test đang dùng trong repo
• hành vi mong muốn mà người dùng hoặc hệ thống sẽ nhìn thấy
• mọi ràng buộc về API shape, backward compatibility hoặc performance

Nếu thiếu ngữ cảnh này, agent vẫn có thể áp dụng TDD một cách máy móc, nhưng rất dễ chọn sai cấp độ test hoặc tạo ra các test hợp với công cụ hơn là hợp với codebase.

Biến một yêu cầu còn thô thành prompt sẵn sàng cho TDD

Prompt yếu:

Add support for password reset.

Prompt tốt hơn:

Use the test-driven-development skill. We need password reset in the existing Node/Express app. Write the first failing integration or service-level test before any production code. Verify the failure is for missing reset behavior, not setup issues. Then implement the minimum code to pass. Keep the current route style, use Jest, and avoid changing unrelated auth flows.

Phiên bản mạnh hơn này cho agent đủ ngữ cảnh để chọn đúng test đầu tiên và tuân thủ vòng lặp red-green-refactor.

Dùng skill này như một workflow theo từng bước, không phải một lần sinh ra tất cả

Một cách dùng test-driven-development hiệu quả trong thực tế là:

1. Chỉ yêu cầu test fail đầu tiên.
2. Review xem lỗi fail đó có nhắm đúng hành vi cần thay đổi hay không.
3. Yêu cầu phần implementation tối thiểu để test pass.
4. Chỉ yêu cầu refactor sau khi đã green.
5. Lặp lại quy trình với lát cắt hành vi nhỏ tiếp theo.

Cách này cho đầu ra tốt hơn nhiều so với việc yêu cầu toàn bộ tính năng trong một lần, vì skill được thiết kế xoay quanh các bước tăng dần nhỏ và đã được kiểm chứng.

Xác minh đúng giai đoạn “red”

Một điểm rất quan trọng trong test-driven-development guide là chỉ có test fail thôi vẫn chưa đủ. Lỗi fail đó phải chứng minh rằng test đang nhắm đúng vào hành vi còn thiếu. Nếu test fail vì import lỗi, fixture hỏng hoặc setup không liên quan, thì vòng lặp TDD thực ra vẫn chưa bắt đầu.

Khi viết prompt, hãy yêu cầu agent nói rõ vì sao test fail và vì sao đó là kiểu fail đúng cần thấy.

Chọn đúng test đầu tiên

Test đầu tiên tốt nhất thường nhắm vào thay đổi hành vi nhỏ nhất nhưng vẫn có ý nghĩa từ bên ngoài. Các điểm khởi đầu tốt gồm:

• tái hiện một bug
• một business rule
• một thay đổi ở response của endpoint
• một hành vi của domain method
• một tương tác UI có tác động rõ với người dùng

Các điểm khởi đầu kém phù hợp gồm kịch bản end-to-end quá lớn, snapshot coverage quá rộng, hoặc các test khóa chặt chi tiết implementation quá sớm.

Áp dụng hướng dẫn anti-pattern khi mocks xuất hiện

File hỗ trợ testing-anti-patterns.md rất quan trọng nếu agent bắt đầu lạm dụng mocks. Skill cảnh báo rất rõ về việc test hành vi của mock thay vì hành vi thật. Điều này đặc biệt đáng chú ý với test-driven-development for Test Automation, nơi AI agent thường tạo assertion dựa trên mock placeholder vì chúng dễ làm cho pass hơn so với đầu ra thật.

Nếu một test chỉ đang kiểm tra rằng mock được render, mock được gọi theo cách quá tầm thường, hoặc phải thêm một method chỉ phục vụ test vào code production, hãy dừng lại và thu hẹp lại phạm vi test.

Yêu cầu agent giữ đúng “iron law”

Nếu model đã lỡ phác thảo implementation trước, hướng dẫn của chính skill là rất nghiêm ngặt: xóa code production đó đi và bắt đầu lại từ một test đang fail. Trong thực tế, bạn không cần làm quá lên, nhưng nên chỉ rõ rằng agent phải bỏ qua phần implementation mang tính suy đoán trước đó và sinh lại theo đúng chuỗi test-first.

Câu chữ hữu ích:

Do not continue from implementation-first code. Restart with a failing test and derive the implementation from that test.

Gắn skill này với test stack của repository

Skill tập trung vào quy trình, nên bạn cần neo nó vào stack đang dùng:

• pytest cho service Python
• Jest hoặc Vitest cho logic JS/TS
• RSpec cho Ruby
• JUnit cho Java
• Playwright hoặc công cụ tương tự chỉ khi hành vi đó thực sự thuộc cấp độ trình duyệt

Nếu repo của bạn đã có test pyramid rõ ràng, hãy nói cho agent biết thay đổi này nên nằm ở đâu. Nếu không, model có thể mặc định chọn kiểu test dễ thấy nhất thay vì kiểu test rẻ nhất nhưng vẫn đủ giá trị.

Ví dụ prompt cho công việc repository thực tế

Một prompt test-driven-development skill tốt sẽ như sau:

Use the test-driven-development skill for a bug fix. In billing/invoice_service.py, invoices with zero-amount adjustments should remain payable if tax is still due. Start by writing the smallest failing pytest that reproduces the current bug. Confirm the failure is caused by the missing business rule, not fixture issues. Then implement the minimum fix, run or describe the expected green result, and suggest any safe refactor only after the test passes.

Prompt này cung cấp rõ hành vi, vị trí code, framework và tiêu chí review.

Câu hỏi thường gặp về skill test-driven-development

Có đáng cài test-driven-development nếu tôi đã biết TDD không?

Có, nếu vấn đề chính của bạn là khiến AI agent thực sự làm theo TDD thay vì chỉ nói về TDD. test-driven-development skill hữu ích không hẳn như một công cụ dạy học, mà như một ràng buộc hành vi dành cho model.

Skill này có thân thiện với người mới bắt đầu không?

Nhìn chung là có. Workflow đơn giản và rõ ràng. Phần khó hơn với người mới là chọn test đầu tiên cho đúng và chọn đúng cấp độ test. Nếu bạn chưa quen với testing, hãy dùng skill này cho các bug fix nhỏ trước thay vì áp dụng ngay cho tính năng mới quá rộng.

Khi nào test-driven-development không phải lựa chọn phù hợp?

Nó kém phù hợp hơn với prototype dùng một lần, generated code hoặc các chỉnh sửa thuần cấu hình, trừ khi rủi ro sai sót cao và người review vẫn muốn giữ kỷ luật test-first. Tài liệu nguồn cũng nói rõ đây là các trường hợp ngoại lệ nên được trao đổi với con người cùng làm.

Skill này khác prompt thông thường ở điểm nào?

Prompt thông thường hay nói kiểu “implement X và add tests”. Skill này thay đổi thứ tự công việc và xem thứ tự đó là điều không được phép phá vỡ. Chính trình tự này mới là giá trị thực, vì nó giúp giảm implementation mang tính ảo đoán và tăng khả năng review.

Skill này có bao gồm cả phần setup framework không?

Không quá sâu. test-driven-development install thì đơn giản, nhưng bản thân skill không cung cấp tài liệu setup chuyên biệt và đầy đủ cho từng framework. Nó giả định rằng bạn có thể chỉ cho agent test stack hiện có hoặc các quy ước sẵn có trong repository.

Có thể dùng test-driven-development cho refactoring không?

Có. Đây là một lựa chọn tốt cho refactoring khi hành vi cần được giữ ổn định. Mẫu làm việc thực tế là khóa hành vi hiện tại bằng test trước, sau đó refactor dưới sự bảo vệ của các test đang green.

Skill này có phù hợp cho UI và end-to-end testing không?

Đôi khi có, nhưng cần cẩn thận. Với công việc UI, file anti-pattern đặc biệt quan trọng vì AI dễ trôi sang việc assert sự hiện diện của mock hoặc các dấu vết implementation. Hãy bắt đầu từ hành vi người dùng thật nhỏ nhất mà bạn có thể kiểm chứng.

Cách cải thiện skill test-driven-development

Hãy mô tả hành vi, đừng áp sẵn cách giải

Để có test-driven-development usage tốt hơn, hãy mô tả hành vi mong muốn và các ràng buộc thay vì áp đặt sẵn cách triển khai. TDD phát huy hiệu quả nhất khi test xác định kết quả đầu ra, còn code được rút ra từ các kiểm chứng đó.

Đầu vào tốt hơn:
Users should see an error when uploading files over 10MB.

Đầu vào kém hơn:
Add a fileSizeValidator class and call it from the controller.

Cách thứ nhất để lại khoảng trống cho một implementation tối thiểu và sạch hơn.

Chỉ rõ cấp độ test bạn muốn

Nhiều kết quả kém đến từ việc chọn sai phạm vi test. Hãy nói rõ với agent bạn muốn:

• business logic ở cấp unit
• integration quanh service hoặc API
• hành vi ở cấp trình duyệt

Chỉ riêng lựa chọn này thường ảnh hưởng nhiều hơn bất kỳ chi tiết prompt nào khác.

Buộc tiến độ phải nhỏ hơn

Một lỗi phổ biến là yêu cầu quá nhiều trong một vòng lặp. Nếu model viết cả một test suite rộng và implementation lớn cùng lúc, hãy thu hẹp lại:

Pick one failing test that captures the first slice of behavior. Do not implement the whole feature yet.

Làm vậy sẽ giữ nguyên vòng lặp test-driven-development.

Yêu cầu giải thích vì sao test đầu tiên là đúng

Hãy yêu cầu agent giải thích:

• vì sao test này là lát cắt nhỏ nhất nhưng vẫn hữu ích
• chính xác lỗi fail nào được kỳ vọng
• vì sao lỗi fail đó chứng minh hành vi đang còn thiếu

Cách này nâng chất lượng đầu ra vì nó buộc các giả định ẩn phải lộ ra trước khi bắt đầu implementation.

Theo dõi anti-pattern từ sớm

Các dấu hiệu xuống chất lượng thường gặp nhất là:

• test mock thay vì test hành vi
• thêm method chỉ phục vụ test vào code production
• viết test pass trước rồi vẫn gọi đó là TDD
• chọn assertion gắn chặt với chi tiết implementation
• bỏ qua bước refactor sau khi đã green

Nếu thấy một trong các dấu hiệu này, hãy dừng vòng lặp và yêu cầu một test đầu tiên đúng hơn thay vì vá víu xung quanh nó.

Nêu rõ quy ước của repository

Skill hoạt động tốt hơn khi bạn nói rõ:

• quy ước đặt tên test
• vị trí đặt test
• pattern dùng cho fixture
• chính sách mocking
• kiểu assertion ưu tiên

Vì repository này chỉ có phần tài liệu hỗ trợ tương đối nhẹ, các quy ước cục bộ như vậy ảnh hưởng trực tiếp tới chất lượng đầu ra.

Lặp tiếp sau kết quả đầu tiên

Sau kết quả đầu tiên, đừng chỉ nói “làm tiếp”. Hãy hỏi các câu tiếp theo có mục tiêu rõ ràng:

• Can you make the failing test narrower?
• Is this failure due to setup or missing behavior?
• Can we remove this mock and test real behavior instead?
• What is the minimum code needed to pass?
• What refactor is now safe with tests green?

Đây là cách có đòn bẩy cao nhất để cải thiện test-driven-development skill trong thực tế: giữ agent ở trong vòng lặp thay vì để nó nhảy cóc sang phía trước.

Kết hợp với phán đoán của con người ở các trường hợp ngoại lệ

Skill này được thiết kế để nghiêm ngặt, và đó là điểm mạnh — nhưng cũng có thể bị áp dụng quá tay. Nếu tác vụ chỉ là thay đổi cấu hình thuần túy, làm mới generated code hoặc prototype dùng tạm, hãy cân nhắc xem TDD đầy đủ có đáng với chi phí bỏ ra không. Kết quả sẽ tốt hơn khi dùng skill này ở những nơi mà trình tự test-first thực sự cải thiện chất lượng quyết định, chứ không chỉ ở những nơi nó “có thể” được áp dụng.