tdd

Tổng quan về tdd skill

tdd là một Test-Driven Development skill dành cho việc xây dựng tính năng và sửa lỗi theo vòng lặp đỏ-xanh-refactor. Skill này phù hợp nhất với những kỹ sư muốn có một hướng dẫn tdd thực dụng, giữ test bám theo hành vi chứ không bám vào cách triển khai. Nếu bạn đang làm việc trong một codebase mà refactor diễn ra thường xuyên, interface rất quan trọng, và các test dễ vỡ đang làm bạn chậm lại, skill này sẽ giúp bạn viết những test có thể sống sót qua thay đổi.

Nhiệm vụ cốt lõi rất đơn giản: biến một ý tưởng tính năng còn thô thành một chuỗi bước nhỏ có thể test an toàn. tdd đặc biệt hữu ích cho công việc tự động hóa test, testing theo kiểu integration, và code hưởng lợi từ ranh giới rõ ràng hơn. Quan điểm mạnh nhất của nó là test qua public interface và chỉ mock ở đúng các ranh giới thật sự của hệ thống.

tdd dùng để làm gì

Hãy dùng tdd khi bạn muốn một workflow test-first cho hành vi mới, sửa lỗi, hoặc refactor cần một lớp an toàn. Đây là lựa chọn phù hợp khi bạn đã biết kết quả mong đợi nhưng chưa biết cách triển khai nào là gọn nhất.

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

Repo này không chỉ đơn thuần là “viết test trước.” Nó thúc đẩy một kỷ luật rất cụ thể: tránh chia lát theo chiều ngang, ưu tiên test tập trung vào hành vi, và thiết kế interface dễ test. Nhờ vậy, tdd skill hữu ích hơn một prompt chung chung khi bạn cần những test bền vững thay vì nhanh nhưng dễ gãy.

Khi nào tdd là lựa chọn không phù hợp

Nếu bạn chỉ cần một unit test ngắn hạn, một script dùng rồi bỏ, hoặc một kiểu xác minh nội bộ phụ thuộc nặng vào mock cho các lời gọi bên trong, thì đây có lẽ không phải công cụ đúng. Skill này hướng tới phần mềm mà bạn dự định sẽ refactor, nơi chất lượng test quan trọng hơn số lượng test.

Cách dùng tdd skill

Cài đặt và nạp skill

Dùng lệnh cài đặt của directory cho bước tdd install, rồi mở SKILL.md trước. Sau đó, đọc tiếp tests.md, mocking.md, interface-design.md, refactoring.md, và deep-modules.md để nắm những quy tắc thực sự quyết định chất lượng đầu ra.

Đưa cho skill một hành vi, không phải một giải pháp

Cách dùng tdd hiệu quả nhất luôn bắt đầu từ một kết quả người dùng nhìn thấy được, một input, và một kết quả mong đợi. Cấu trúc prompt tốt:

• “Thêm kiểm tra checkout để cart không hợp lệ trả về lỗi rõ ràng và cart hợp lệ thì hoàn tất thanh toán”
• “Sửa lỗi khiến email trùng nhau tạo ra hai tài khoản”
• “Viết test cho luồng retry đối với payment API, dùng public service interface”

Cấu trúc prompt yếu:

• “Viết test cho checkout”
• “Làm module này testable hơn”
• “Mock database và xác minh function đã được gọi”

Đi theo vòng lặp đỏ-xanh-refactor

Bắt đầu từ hành vi nhỏ nhất có thể quan sát được, viết một test thất bại để chứng minh nó, triển khai tối thiểu để test pass, rồi refactor trong khi giữ test xanh. Đừng gom tất cả test trước rồi mới làm implementation sau; skill này cảnh báo rõ ràng về các lát cắt theo chiều ngang vì chúng tạo ra hành vi tưởng tượng thay vì hành vi đã được kiểm chứng.

Đọc các file này trước

Để thực thi thực tế, hãy ưu tiên:

• SKILL.md cho triết lý và workflow
• tests.md cho các pattern test tốt và xấu
• mocking.md cho nguyên tắc chỉ mock ở ranh giới
• interface-design.md để làm code dễ test hơn
• refactoring.md cho những điểm cần cải thiện sau khi pass xanh đầu tiên

FAQ về tdd skill

tdd chỉ dành cho unit test thôi à?

Không. tdd skill này ưu tiên các test kiểu integration thông qua public interface, nên thường phù hợp hơn cho test automation và behavior testing so với các setup thiên về unit test cô lập.

Tôi có cần mock mọi thứ không?

Không. Một quy tắc cốt lõi trong tdd guide này là chỉ mock ở ranh giới hệ thống như external API, thời gian, tính ngẫu nhiên, hoặc đôi khi là file system hay database. Đừng mock module của chính bạn chỉ để test chạy qua.

Người mới có dùng tdd được không?

Có, nếu họ có thể mô tả hành vi mong đợi một cách rõ ràng. Đường cong học tập chính không nằm ở cú pháp; nó nằm ở việc chọn đúng ranh giới và tránh test theo chi tiết triển khai.

tdd khác gì so với một prompt bình thường?

Một prompt bình thường có thể tạo ra những test chỉ cần biên dịch được là đủ. tdd skill mang tính định hướng hơn: nó thúc đẩy test bắt đầu từ hành vi, chia nhỏ từng bước, và thiết kế interface để test ổn định trong lúc refactor.

Cách cải thiện tdd skill

Bắt đầu với input sắc hơn

Bạn sẽ nhận kết quả tốt hơn từ tdd khi đưa vào hành vi, ranh giới, và ràng buộc. Ví dụ, hãy nói “xây dựng một email sender có thể retry, dùng một service wrapper thật, nhưng mock thời gian và external provider” thay vì “làm cho cái này testable hơn.”

Chú ý các lỗi thất bại thường gặp

Những lỗi lớn nhất là over-mocking, test private method, và viết test mô tả cách code vận hành thay vì điều người dùng nhìn thấy. Nếu bản nháp đầu tiên có vẻ bám quá sát vào chi tiết triển khai, hãy sửa prompt để gọi đúng public API và kết quả quan sát được.

Lặp từ test sang design

Sau output đầu tiên, hãy dùng các phần fail để cải thiện interface design: tham số nhỏ hơn, giá trị trả về rõ hơn, và ít side effect hơn. Nếu code vẫn khó test, vấn đề có thể nằm ở hình dạng API, không phải ở test.

Yêu cầu gợi ý refactor sau khi xanh

Khi hành vi đã được bao phủ, hãy yêu cầu skill chỉ ra duplication, method dài, module quá mỏng, feature envy, hoặc primitive obsession. Đây là lúc tdd skill tạo thêm giá trị: nó giúp bạn đi từ “test pass” sang một design sạch hơn và vẫn dễ test về sau.