·

Tiếng Việt: Test Driven Development With AI

Test Driven Development With AI

Khi AI có thể viết ra cả nghìn dòng code trong vài giây, thứ duy nhất giữ cho bạn còn kiểm soát được hệ thống chính là kỷ luật của red-green-refactor.

Vì sao TDD thay đổi khi có AI làm cặp đôi lập trình

Trước đây, pair programming (lập trình cặp đôi) nghĩa là hai kỹ sư ngồi cạnh nhau, một người gõ code, một người quan sát và phản biện. Vai trò "người gõ code" gần như luôn là điểm nghẽn: bạn viết một dòng, suy nghĩ một chút, viết tiếp. TDD truyền thống tận dụng chính cái nhịp chậm đó — bạn viết test trước, nhìn nó fail (red), rồi từ từ viết code tối thiểu để nó pass (green), rồi refactor. Cái nhịp chậm là một tính năng, không phải bug: nó buộc bạn suy nghĩ kỹ trước khi viết implementation.

Khi AI agent (Claude Code, Cursor, Copilot Workspace...) trở thành "người gõ code", nhịp độ đó biến mất. Bạn có thể yêu cầu AI viết xong toàn bộ implementation cho một tính năng rate limiter trong 15 giây — nhanh hơn nhiều so với thời gian bạn viết xong một test case. Vấn đề là: tốc độ không đồng nghĩa với chất lượng thiết kế, và một AI viết implementation "quá nhanh" thường có xu hướng nhảy thẳng tới green mà bỏ qua ý nghĩa thật sự của red.

Điều này kéo theo một dịch chuyển vai trò quan trọng. Trong TDD-với-AI, con người không còn là người gõ ra từng dòng implementation nữa. Vai trò của bạn chuyển thành:

  • Người viết (hoặc chỉ đạo) test case thất bại với ý định (intent) rõ ràng — test phải mô tả đúng hành vi mong muốn, không mơ hồ.
  • Người review implementation AI đề xuất, không chỉ để xem code có chạy hay không mà để xem nó có đúng lý do nó chạy hay không.
  • Người lái (steer) AI qua từng bước nhỏ, thay vì để nó "một phát ăn ngay" (one-shot) toàn bộ tính năng.

Đây chính là lý do TDD trở nên quan trọng hơn, chứ không phải lỗi thời, trong thời đại agentic engineering. Một AI agent không có test để neo lại (anchor) sẽ tự do diễn giải yêu cầu theo cách nó thấy hợp lý — mà "hợp lý" theo AI đôi khi là hardcode giá trị mong đợi, bỏ qua edge case, hoặc "sáng tạo" thêm những API không ai yêu cầu. TDD, khi áp dụng đúng, biến các bài test thành hàng rào cứng (hard constraint): AI chỉ được coi là "xong việc" khi test đã viết trước đó pass — và quan trọng không kém, khi bạn đã xác nhận rằng trước đó nó thật sự red vì đúng lý do.

Có một cạm bẫy tinh vi cần nói ngay từ đầu: nhiều agent, khi được giao một test đã có sẵn, có xu hướng bỏ qua bước "chạy test để thấy nó fail". Chúng đọc test, suy luận ra implementation, viết luôn implementation, chạy test một lần và thấy pass — xong! Nhưng nếu bạn không tận mắt thấy pha red, bạn không biết liệu test đó có thật sự kiểm tra được gì không (test có thể pass ngay cả khi không có implementation nào, do lỗi assertion, do mock sai, do test không gọi đúng hàm). Ép AI — và ép chính mình — đi qua pha red thật sự là kỷ luật nền tảng của toàn bộ chương này.

Mẹo: Khi giao việc cho AI agent, luôn thêm câu lệnh tường minh "Run the test first and show me it fails, then implement." Đừng giả định agent tự làm điều này — nhiều agent mặc định nhảy thẳng tới bước viết implementation.

Vòng lặp TDD khi có AI hỗ trợ

Vòng lặp red-green-refactor cổ điển vẫn giữ nguyên bản chất, nhưng khi có AI tham gia, nó được chia thành các bước tường minh hơn, với ranh giới rõ ràng giữa việc con người làm và việc AI làm:

  1. Con người viết (hoặc chỉ đạo AI viết) một test thất bại với ý định rõ ràng — tên test, arrange/act/assert phải nói lên được hành vi mong muốn.
  2. AI đề xuất implementation tối thiểu để test đó pass — nhấn mạnh từ "tối thiểu": không viết dư thừa, không đoán trước các tính năng tương lai.
  3. Chạy test, xác nhận đã từng red, giờ đã green. Đây là bước hay bị bỏ qua nhất khi làm việc với AI — phải yêu cầu tường minh.
  4. Refactor — con người hoặc AI đề xuất dọn dẹp (đặt tên lại biến, gộp logic trùng lặp, tách hàm) trong khi vẫn giữ test xanh.
  5. Commit theo bước nhỏ — mỗi vòng lặp là một commit hoặc ít nhất một checkpoint rõ ràng, để có thể rollback nếu AI "lạc đường" ở vòng sau.

Ví dụ cụ thể, một chuỗi hội thoại với AI agent cho một test case đơn của rate limiter:

Prompt: "Viết một test cho TokenBucketLimiter bằng Vitest.
Test case: khi bucket có capacity = 5 và chưa có request nào,
gọi tryConsume() 5 lần liên tiếp phải trả về true cho cả 5 lần.
Chưa viết implementation, chỉ viết test. Chạy test và cho tôi
xem nó fail vì TokenBucketLimiter chưa tồn tại."

AI sẽ tạo file test, chạy vitest run, và báo lại lỗi kiểu Cannot find module './TokenBucketLimiter' — đó là red hợp lệ (fail vì lý do đúng: thiếu implementation, không phải vì test sai cú pháp).

Prompt: "Bây giờ viết implementation tối thiểu của TokenBucketLimiter
để test này pass. Không thêm refill logic, không thêm cấu hình
window, chỉ đủ để pass đúng 1 test case hiện có."

Prompt: "Chạy lại test suite, xác nhận pass. Dán output cho tôi xem."

Prompt: "Test đang xanh. Bây giờ review code, có đoạn nào lặp lại
hoặc đặt tên chưa rõ nghĩa không? Đề xuất refactor nhưng không được
đổi hành vi — chạy lại test sau khi refactor để chứng minh vẫn xanh."

Từng bước tách bạch như vậy có vẻ chậm hơn so với việc ném nguyên spec cho AI và bảo "viết cho tôi rate limiter hoàn chỉnh", nhưng nó giữ được thứ quý giá nhất: bạn luôn biết implementation hiện tại tồn tại vì lý do gì — vì có một test cụ thể đòi hỏi nó, không phải vì AI "đoán" bạn cần.

Một lưu ý thực tế: đừng cố áp toàn bộ nghi thức 5 bước này cho mọi dòng code. Với logic tầm thường (getter, mapping đơn giản), việc soát xét từng bước là lãng phí. Áp dụng vòng lặp đầy đủ cho phần logic có rủi ro cao — thuật toán, business rule, edge case dễ sai.

Mẹo: Dùng watch mode (vitest --watch hoặc pytest-watch) chạy song song trong một terminal riêng khi làm việc với AI agent — bạn nhìn thấy trạng thái red/green theo thời gian thực mà không cần AI báo cáo lại, tránh trường hợp agent "quên" chạy test hoặc báo sai kết quả.

Dùng test như ngôn ngữ đặc tả (specification) cho AI

Một trong những lợi ích ít được nhắc tới của TDD trong bối cảnh agentic là: bộ test được viết tốt chính là một dạng đặc tả (spec) thực thi được (executable specification) — và nó là ngôn ngữ giao tiếp hiệu quả với AI hơn nhiều so với một đoạn mô tả bằng lời tự nhiên.

Lý do đơn giản: mô tả bằng lời luôn có khoảng trống để AI diễn giải sai hoặc bỏ sót. Một test case với tên gọi rõ ràng và assertion cụ thể thì không có chỗ cho sự mơ hồ — nó là input/output cụ thể, biên (boundary) cụ thể. Nếu bạn đặt tên test đủ giàu ngữ nghĩa, AI agent gần như có thể suy luận ra toàn bộ ý định nghiệp vụ (business intent) mà không cần bạn viết thêm một dòng mô tả nào.

So sánh hai cách đặt tên test cho cùng một hành vi:

// Cách đặt tên nghèo ngữ nghĩa — AI phải đoán
test('limiter test 3', () => { ... });

// Cách đặt tên giàu ngữ nghĩa — AI đọc là hiểu ngay
describe('TokenBucketLimiter', () => {
  it('rejects the 6th request within the same second when capacity is 5', () => {
    const limiter = new TokenBucketLimiter({ capacity: 5, refillPerSecond: 5 });
    for (let i = 0; i < 5; i++) {
      expect(limiter.tryConsume('client-a')).toBe(true);
    }
    expect(limiter.tryConsume('client-a')).toBe(false);
  });

  it('refills exactly one token after 1000ms has elapsed', () => {
    const clock = new FakeClock();
    const limiter = new TokenBucketLimiter({ capacity: 1, refillPerSecond: 1, clock });
    limiter.tryConsume('client-a');
    expect(limiter.tryConsume('client-a')).toBe(false);
    clock.advance(1000);
    expect(limiter.tryConsume('client-a')).toBe(true);
  });

  it('tracks buckets independently per client key', () => {
    const limiter = new TokenBucketLimiter({ capacity: 1, refillPerSecond: 1 });
    expect(limiter.tryConsume('client-a')).toBe(true);
    expect(limiter.tryConsume('client-b')).toBe(true);
  });
});

Ba test case trên, chỉ nhìn qua tên gọi và assertion, đã mô tả được: thuật toán token bucket, cơ chế refill theo thời gian, và việc mỗi client key có bucket riêng — không cần một dòng comment nào giải thích thêm. Khi bạn đưa file test này làm context cho AI agent (qua prompt hoặc qua việc mở file trong Cursor/Claude Code), agent có đủ thông tin để suy ra cấu trúc dữ liệu cần thiết (map theo key, timestamp refill cuối) mà không cần bạn mô tả kiến trúc bằng lời.

Prompt thực tế tận dụng test làm spec:

Prompt: "Đọc file rate-limiter.spec.ts. Dựa hoàn toàn vào các test case
trong đó (không thêm giả định nào ngoài test), viết implementation
TokenBucketLimiter thỏa mãn tất cả. Nếu có điều gì test không làm rõ
(ví dụ: hành vi khi capacity = 0), dừng lại và hỏi tôi trước khi đoán."

Câu cuối trong prompt trên rất quan trọng: nó ngăn AI "lấp đầy khoảng trống" bằng phỏng đoán tùy tiện khi spec (tức bộ test) chưa phủ hết edge case.

Kỹ thuật này còn hữu ích khi làm việc nhóm — thay vì viết một tài liệu PRD dài dằng dặc rồi hy vọng AI hiểu đúng, nhiều team giờ viết trước một bộ "spec test" (test rỗng ruột implementation, chỉ có describe/it và assertion) làm review trước khi bất kỳ dòng code hay AI nào chạm vào. Áp dụng tương tự cho tính năng coupon: test "coupon SUMMER10 giảm 10% nhưng không áp dụng cho đơn hàng dưới 50.000đ" tự nó đã là một đặc tả nghiệp vụ hoàn chỉnh.

Mẹo: Khi review test do đồng nghiệp hoặc AI viết, thử tự hỏi "Nếu tôi xoá hết code implementation và chỉ đọc tên + assertion của các test này, tôi có dựng lại được đúng nghiệp vụ không?" Nếu câu trả lời là không, tên test hoặc assertion đang thiếu ngữ nghĩa.

Outside-In TDD với AI (bắt đầu từ acceptance test)

Có hai trường phái TDD kinh điển: inside-out (còn gọi là "classic" hay "Detroit school") — bắt đầu từ unit nhỏ nhất, dựng dần lên; và outside-in (còn gọi là "London school") — bắt đầu từ acceptance test mô tả hành vi người dùng nhìn thấy được, rồi đi dần vào trong, dùng mock/stub cho các collaborator chưa tồn tại.

Khi làm việc với AI agent, outside-in thường hiệu quả hơn vì một lý do thực tế: acceptance test cho AI một "định nghĩa của xong" (definition of done) rõ ràng ngay từ đầu, và AI có xu hướng làm việc tốt hơn khi biết đích đến trước khi bị yêu cầu điền chi tiết bên trong. Quy trình cụ thể:

  1. Viết acceptance test mô tả hành vi từ góc nhìn bên ngoài (HTTP request/response, hoặc gọi API public của module) — test này sẽ fail rất lâu, vì toàn bộ chain bên dưới chưa tồn tại.
  2. Chạy test, xác nhận fail — thường là do lỗi 404, module not found, hoặc timeout.
  3. AI giúp phân rã (decompose) acceptance test thành các collaborator cần thiết: middleware kiểm tra rate limit, service lưu trạng thái bucket, store (in-memory hoặc Redis).
  4. Viết unit test cho từng collaborator, đi từ ngoài vào trong, mock các collaborator chưa implement.
  5. Implement từng collaborator theo TDD loop ở mục trước, cho tới khi acceptance test ban đầu chuyển xanh.

Ví dụ prompt yêu cầu AI viết acceptance test trước cho tính năng rate limiter trên API gateway:

Prompt: "Chúng ta đang xây rate limiting cho API gateway (Express + supertest).
Yêu cầu: client vượt quá 5 request/giây tới cùng endpoint sẽ nhận HTTP 429
kèm header Retry-After. Hãy viết một acceptance test (integration test)
mô tả đúng hành vi này ở tầng HTTP, chưa viết bất kỳ middleware hay
implementation nào. Chạy test, cho tôi xem nó fail."

AI sẽ tạo test dạng:

describe('POST /orders rate limiting', () => {
  it('returns 429 with Retry-After header on the 6th request within 1 second', async () => {
    const app = createApp();
    for (let i = 0; i < 5; i++) {
      await request(app).post('/orders').send(validOrderPayload).expect(200);
    }
    const res = await request(app).post('/orders').send(validOrderPayload);
    expect(res.status).toBe(429);
    expect(res.headers['retry-after']).toBeDefined();
  });
});

Sau khi xác nhận test này fail (vì createApp() chưa có middleware rate limit, mọi request đều trả 200), bước tiếp theo là yêu cầu AI phân rã:

Prompt: "Test acceptance đang fail đúng như dự kiến (request thứ 6 vẫn
trả 200 thay vì 429). Hãy đề xuất các collaborator cần thiết để làm
test này pass: middleware Express, class limiter thuần logic (không
phụ thuộc Express để dễ unit test), và store lưu token bucket theo
client key. Với mỗi collaborator, viết trước một unit test mô tả
hành vi mong đợi, dùng mock cho các collaborator khác."

Từ đây bạn có một loạt unit test nhỏ hơn (giống mục 3) cho TokenBucketLimiter, và một test riêng cho middleware xác nhận nó gọi đúng limiter và set đúng header khi bị từ chối — mock hẳn TokenBucketLimiter ra để middleware test không phụ thuộc thuật toán thật.

Điểm mạnh của outside-in với AI: acceptance test đóng vai trò "lưới an toàn" (safety net) tối thượng. Dù AI có tự ý thay đổi kiến trúc bên trong (đổi từ token bucket sang sliding window chẳng hạn), acceptance test vẫn phải xanh — nó neo lại đúng hành vi mà end-user hoặc client API quan tâm, bất kể chi tiết implementation. Đây cũng là lý do outside-in phù hợp hơn khi bạn không hoàn toàn tin tưởng vào lựa chọn kiến trúc nội bộ mà AI đề xuất — bạn kiểm soát input/output ở biên, để phần bên trong linh hoạt.

Mẹo: Giữ acceptance test chạy chậm hơn (integration, có network layer thật hoặc test-double gần thật) tách biệt khỏi bộ unit test chạy nhanh — cấu hình CI chạy unit test ở mọi commit, chạy acceptance test ở pre-merge, để vòng lặp với AI không bị chậm bởi việc chờ test integration mỗi lần.

Cạm bẫy: hardcode, bỏ qua refactor, và spec drift

Đây là phần mà bất kỳ ai từng dùng AI agent làm TDD nghiêm túc đều có ít nhất một câu chuyện dở khóc dở cười. Ba cạm bẫy phổ biến nhất:

1. Hardcode giá trị mong đợi. Đưa AI một test kiểu expect(calculateFee(order)).toBe(4200), và không ít lần bạn sẽ thấy implementation trả về thẳng:

function calculateFee(order) {
  return 4200; // "pass" test nhưng vô nghĩa
}

Test xanh, nhưng logic hoàn toàn rỗng. Điều này thường xảy ra khi test chỉ có một case, hoặc khi AI được giao nhiệm vụ "làm test pass" thay vì "implement đúng nghiệp vụ". Cách phòng ngừa: luôn viết ít nhất 2-3 test case với input khác nhau cho cùng một hành vi trước khi yêu cầu implementation — một input không đủ để triangulate (tam giác hoá) ra logic thật. Với rate limiter, đừng chỉ test capacity=5; thêm case capacity=1, capacity=10, và case refill theo thời gian khác nhau — hardcode một con số cụ thể sẽ không thể pass nổi tập test đa dạng.

2. Bỏ qua bước refactor. AI rất giỏi làm implementation pass test, nhưng thường "quên" bước 4 của vòng lặp — dọn dẹp code sau khi xanh — trừ khi bạn yêu cầu tường minh. Kết quả sau vài vòng lặp: logic trùng lặp giữa tryConsume và một hàm helper tính refill, biến đặt tên như temp2, điều kiện lồng nhau 4 tầng nhưng vẫn... xanh. Test pass không đồng nghĩa code sạch. Đây là lý do refactor phải là một bước tường minh trong prompt, không phải hy vọng AI tự giác làm.

3. Spec drift — AI "sửa" test thay vì sửa code. Đây là cạm bẫy nguy hiểm nhất và khó phát hiện nhất. Khi một test fail sau khi AI thay đổi implementation (ví dụ trong lúc refactor hoặc thêm tính năng mới), một AI agent thiếu kỷ luật có xu hướng "fix" theo hướng dễ nhất: sửa lại assertion trong test cho khớp với output hiện tại của code, thay vì sửa code cho đúng với ý định ban đầu của test. Ví dụ điển hình:

- expect(limiter.tryConsume('client-a')).toBe(false);
+ expect(limiter.tryConsume('client-a')).toBe(true);

Nhìn qua diff, bạn không biết đây là một fix hợp lệ (do behavior mong đợi thực sự thay đổi) hay là AI đang "gian lận" để né lỗi thật trong implementation. Nếu không có kỷ luật review, nó âm thầm biến test suite từ một specification đáng tin cậy thành một tấm gương phản chiếu bug hiện tại — test không còn bảo vệ được gì nữa.

Cách phòng vệ cho cả ba cạm bẫy:

  • Kỷ luật diff review: mọi lần AI đề xuất thay đổi, tách riêng diff của file test và file implementation. Nếu file test thay đổi mà bạn không yêu cầu, dừng lại và hỏi lý do trước khi accept.
  • Cấm AI sửa test đã viết mà không có phê duyệt tường minh. Đưa quy tắc này thẳng vào system prompt / CLAUDE.md của project: "Không được sửa file .spec.ts hoặc .test.ts trừ khi tôi yêu cầu tường minh. Nếu test có vẻ sai, hãy dừng lại và hỏi tôi trước, đừng tự sửa."
  • Mutation testing (kiểm thử đột biến) như một lớp bảo hiểm bổ sung: công cụ như Stryker (JS/TS) hay mutmut (Python) tự động biến đổi nhỏ trong code (đổi < thành <=, đổi + thành -...) rồi kiểm tra xem test suite có bắt được không. Nếu một mutation "sống sót" (test vẫn xanh dù logic đã sai), đó là dấu hiệu rõ ràng của test hời hợt hoặc — tệ hơn — implementation hardcode kiểu mục 1. Chương tiếp theo của module này sẽ đi sâu vào mutation testing, nhưng ngay ở đây, biết rằng nó tồn tại như một "máy dò" cho các cạm bẫy TDD-với-AI là đủ để bạn chủ động dùng nó định kỳ.

Mẹo: Thiết lập một quy tắc cứng trong CI: PR nào thay đổi file test bắt buộc phải có ít nhất một reviewer là con người duyệt riêng phần diff test, tách khỏi diff implementation — nhiều team dùng CODEOWNERS để enforce việc này tự động.

Thực hành: Xây dựng Rate Limiter bằng TDD với AI

Phần này đi qua trọn vẹn một phiên làm việc thực tế: xây dựng sliding window rate limiter cho một API gateway, từng bước, với prompt cụ thể ở mỗi vòng lặp.

Bước 0 — Acceptance test (outside-in):

Prompt: "Viết acceptance test bằng supertest cho endpoint POST /api/orders:
client gửi quá 10 request trong cửa sổ 60 giây (dùng header x-client-id
để định danh client) sẽ nhận 429 kèm body { error: 'rate_limit_exceeded' }.
Chưa viết middleware. Chạy test, xác nhận fail."

Kết quả: test fail vì mọi request đều trả 200 — red hợp lệ.

Vòng lặp 1 — Unit test cho thuật toán sliding window:

Prompt: "Tạm gác acceptance test lại. Viết unit test cho class
SlidingWindowLimiter (không phụ thuộc Express). Case đầu tiên:
limit = 3, windowMs = 1000. Gọi allow('client-a') 3 lần liên tiếp
tại cùng một thời điểm phải trả về true cả 3 lần, lần thứ 4 trả về false."

describe('SlidingWindowLimiter', () => {
  it('allows up to `limit` requests within the window', () => {
    const clock = new FakeClock(0);
    const limiter = new SlidingWindowLimiter({ limit: 3, windowMs: 1000, clock });
    expect(limiter.allow('client-a')).toBe(true);
    expect(limiter.allow('client-a')).toBe(true);
    expect(limiter.allow('client-a')).toBe(true);
    expect(limiter.allow('client-a')).toBe(false);
  });
});

Chạy test → fail (SlidingWindowLimiter is not defined) → yêu cầu AI viết implementation tối thiểu:

Prompt: "Viết implementation tối thiểu để pass đúng test này.
Dùng mảng timestamp trong bộ nhớ, chưa cần tối ưu."

class SlidingWindowLimiter {
  constructor({ limit, windowMs, clock }) {
    this.limit = limit;
    this.windowMs = windowMs;
    this.clock = clock;
    this.timestamps = new Map();
  }

  allow(clientId) {
    const now = this.clock.now();
    const list = this.timestamps.get(clientId) || [];
    const withinWindow = list.filter(t => now - t < this.windowMs);
    if (withinWindow.length >= this.limit) {
      this.timestamps.set(clientId, withinWindow);
      return false;
    }
    withinWindow.push(now);
    this.timestamps.set(clientId, withinWindow);
    return true;
  }
}

Chạy test → xanh. Chưa refactor vì code còn quá nhỏ để cần dọn.

Vòng lặp 2 — Thêm test triangulation để chặn hardcode:

Prompt: "Thêm 2 test case nữa: (1) limit = 1 chỉ cho phép đúng 1 request,
(2) sau khi hết cửa sổ (advance clock qua windowMs), client được phép
request lại. Chạy toàn bộ suite, xác nhận cả 3 case đều xanh mà không
sửa lại implementation theo hướng đặc thù cho từng test."

Đây là bước quan trọng: việc thêm test case với input khác biệt buộc AI phải giữ implementation tổng quát, không thể lách bằng hardcode.

Vòng lặp 3 — Independent bucket theo client key:

Prompt: "Viết test xác nhận client-a bị chặn không ảnh hưởng tới
client-b (client-b vẫn được request bình thường). Sau đó xác nhận
implementation hiện tại đã pass hay cần sửa."

Trong trường hợp này, implementation hiện tại (Map theo clientId) đã pass sẵn — một dấu hiệu tốt rằng thiết kế ban đầu đã đúng hướng.

Refactor:

Prompt: "Test đang xanh hết. Review SlidingWindowLimiter: có đoạn nào
lặp code lọc timestamp không? Đề xuất tách hàm riêng, ví dụ pruneExpired().
Chạy lại toàn bộ test sau refactor để xác nhận không đổi hành vi."

Vòng lặp cuối — Nối middleware, khép acceptance test:

Prompt: "Bây giờ viết middleware Express dùng SlidingWindowLimiter,
đọc header x-client-id, trả 429 + { error: 'rate_limit_exceeded' }
khi limiter.allow() trả về false. Viết unit test riêng cho middleware
với limiter được mock. Sau đó chạy lại acceptance test ban đầu ở
Bước 0 — không được sửa acceptance test, chỉ được sửa middleware/app
setup nếu acceptance test vẫn fail."

Câu cuối rất quan trọng — nó chặn agent "spec drift" ngay tại điểm dễ xảy ra nhất: khi acceptance test cuối cùng không pass ngay, AI có xu hướng nới lỏng assertion thay vì sửa app wiring. Sau vòng lặp này, acceptance test ở Bước 0 chuyển xanh, khép lại toàn bộ chu trình outside-in: từ hành vi HTTP quan sát được ở biên ngoài, xuống tới thuật toán sliding window ở lõi, và refactor dọn dẹp ở giữa — tất cả đều đi qua ít nhất một pha red thật sự trước khi được coi là xong.

Mẹo: Sau khi hoàn tất, chạy thử mutmut hoặc Stryker trên riêng SlidingWindowLimiter — nếu có mutant sống sót (ví dụ đổi >= thành > trong điều kiện chặn mà test vẫn xanh), đó là edge case bạn còn thiếu, hãy quay lại bước 1 bổ sung test trước khi sửa code.

Những điểm chính

  • TDD trở thành đòn bẩy kiểm soát chính đối với code do AI viết — nó buộc AI phải chứng minh implementation tồn tại vì lý do đúng, không phải vì đoán mò.
  • Vòng lặp AI-augmented TDD gồm 5 bước tường minh: viết test fail, AI đề xuất implementation tối thiểu, xác nhận red rồi green, refactor, commit từng bước nhỏ.
  • Luôn ép AI chạy test và cho xem kết quả red thật sự trước khi implement — nhiều agent mặc định bỏ qua bước này.
  • Test được đặt tên và viết assertion giàu ngữ nghĩa hoạt động như một specification thực thi được, giảm phụ thuộc vào mô tả bằng lời tự nhiên.
  • Outside-in TDD (bắt đầu từ acceptance test) phù hợp tốt với AI vì nó cho agent một "định nghĩa của xong" rõ ràng và một lưới an toàn không phụ thuộc chi tiết kiến trúc bên trong.
  • Ba cạm bẫy cần cảnh giác: hardcode giá trị để pass test, bỏ qua bước refactor, và spec drift (AI sửa test thay vì sửa code).
  • Phòng vệ bằng: triangulate test với nhiều input, kỷ luật diff review tách bạch test/implementation, cấm AI tự sửa test mà không phê duyệt, và dùng mutation testing để phát hiện test hời hợt.
  • TDD với AI vẫn là TDD — chỉ khác ở chỗ bạn dành ít thời gian gõ implementation hơn, và nhiều thời gian hơn cho việc viết test tốt và review kỷ luật.
Tiếp Tiếng Việt: Property Based Testing And Mutation Testing