Ứng dụng của bạn đi kèm bằng chứng
Kliv viết kiểm thử thật cho các ứng dụng nó xây — và chạy chúng trong trình duyệt thật, trên bản sao dùng một lần của cơ sở dữ liệu, với biên nhận cho mọi tác dụng phụ. Cùng vòng lặp viết ứng dụng cũng viết kiểm thử và đưa chúng về xanh.
Kiểm thử tích hợp sẵn
Không phải mã sinh ra rồi cầu may
Phần lớn trình tạo bằng AI sinh một ứng dụng rồi giao lại — nó có thật sự hoạt động hay không là vấn đề của bạn. Kliv sở hữu toàn bộ stack mà ứng dụng chạy trên đó: trình duyệt, API, quy tắc bảo mật, cơ sở dữ liệu, pipeline email. Đó là thứ khiến bằng chứng khả thi. Kiểm thử không phải thứ gắn thêm về sau; chúng là một phần của cách ứng dụng được xây, chạy bởi cùng vòng lặp đã viết mã.
Cấu trúc của một lần chạy
Cách tốt nhất để hiểu hệ thống kiểm thử là đi theo một lần chạy từ dòng đầu tiên đến phán quyết. Đây là điều xảy ra — và điều không bao giờ chạm vào dữ liệu thật của bạn.
Viết
AI viết kiểm thử unit khi nó xây — Vitest và Testing Library thật, stack tiêu chuẩn trong ngành, không phải bản mô phỏng độc quyền. Yêu cầu bao phủ một luồng và nó viết một Scenario: điều hướng, bấm, điền, assert, bằng thuật ngữ ngữ nghĩa — nút theo tên, trường theo nhãn — không phải đường dẫn CSS mong manh chết ở lần thiết kế lại tiếp theo.
Chạy trong trình duyệt thật
Kiểm thử thực thi trong trình duyệt thật trên ứng dụng thực tế của bạn — render thật, đăng nhập thật, bảo mật cấp hàng thật. Không mock thứ quan trọng: nếu một thay đổi quyền cho phép một người dùng đọc dữ liệu của người khác, kiểm thử thất bại như ứng dụng của bạn sẽ thất bại.
Fork cơ sở dữ liệu
Trước khi một Scenario chạm vào dữ liệu, nó nhận một fork dùng một lần của cơ sở dữ liệu — cùng schema, cùng quy tắc, không có hàng nào của bạn gặp rủi ro. Tạo, sửa và xóa chạy thật và ghi vào fork; tệp và trạng thái commerce của bạn cũng được clone theo cùng cách. Khi lần chạy kết thúc, fork bị bỏ đi.
Bắt lưu lượng đi ra
Email, webhook và cuộc gọi bên thứ ba được bắt lại, không gửi đi. Một kiểm thử có thể assert rằng email chào mừng sẽ được gửi, tới ai, với nội dung gì — và không email nào rời khỏi hệ thống. Các tích hợp của bạn im lặng trong khi logic được chạy thật.
Biên nhận
Mỗi lần chạy ghi lại ứng dụng thật sự đã làm gì: hàng nào nó ghi, email nào nó sẽ gửi, cuộc gọi bên ngoài nào nó đã thử — từng mục được đánh dấu là chấp nhận, bắt lại hoặc từ chối, kèm lý do, xuống đến quy tắc bảo mật đã chặn một lượt ghi. Không chỉ đỏ hay xanh: chuyện gì đã xảy ra, và vì sao.
Phán quyết
Kết quả quay lại theo từng check, từng file — assertion thất bại, bước bị gãy, cùng biên nhận của lần chạy. Thất bại có cấu trúc là điểm chính: đó là thứ cho cùng vòng lặp đã viết mã tìm lỗi, sửa và chạy lại.
Cổng chặn
Kết quả kiểm thử chặn publish. Một Scenario thất bại dừng bản phát hành trước khi nó đến người dùng — để “nó chạy lúc chúng ta xây” trở thành “nó chạy bây giờ”, được xác minh ở mọi thay đổi thay vì nhớ lại từ bản demo.
Hệ thống kiểm thử biết làm gì
Tích hợp sẵn, chạy cho bạn và đọc được khi bạn muốn xem.
Stack kiểm thử thật
Vitest, Testing Library và jest-dom thật chạy trong trình duyệt — cùng các công cụ đội ngũ chuyên nghiệp dùng, nên kiểm thử đọc như kiểm thử, không như phương ngữ của nhà cung cấp.
Kiểm thử Scenario
Luồng end-to-end được viết bằng thuật ngữ ngữ nghĩa — tìm nút theo vai trò, trường theo nhãn — điều khiển ứng dụng thật như một người dùng.
Cơ sở dữ liệu dùng một lần
Mọi Scenario chạy trên một fork của cơ sở dữ liệu thật. Các lượt ghi được chấp nhận, assert và loại bỏ — dữ liệu của bạn không bao giờ là một phần của thí nghiệm.
Không gì rò ra ngoài
Lần chạy kiểm thử bắt email, webhook và cuộc gọi connector thay vì gửi chúng — bạn có thể chứng minh chúng xảy ra mà không để chúng thật sự xảy ra.
Mỗi lần chạy có biên nhận
Một sổ cái của mọi tác dụng phụ mà kiểm thử gây ra — được chấp nhận, bắt lại hoặc từ chối, kèm lý do. Dấu vết, không chỉ đèn giao thông.
Lịch sử và cổng chặn
Các lần chạy được theo dõi theo thời gian, và kiểm thử vượt qua chặn publish — xác minh là trạng thái thường trực của ứng dụng, không phải sự kiện một lần.
Câu hỏi thường gặp
Ai viết kiểm thử?
AI viết, trong lúc xây — kiểm thử unit mặc định, trong stack tiêu chuẩn. Yêu cầu bao phủ một luồng và nó viết một Scenario cho luồng đó. Mọi kiểm thử là mã đọc được trong ứng dụng của bạn; bạn có thể xem bất kỳ phần nào, và không bao giờ bắt buộc phải làm vậy.
Kiểm thử có chạm vào dữ liệu thật của tôi không?
Không. Scenario chạy trên một fork dùng một lần của cơ sở dữ liệu — các lượt ghi được chấp nhận ở đó và bị bỏ cùng fork khi lần chạy kết thúc. Tệp và trạng thái commerce cũng được clone theo cùng cách, nên ngay cả kiểm thử xóa mọi thứ cũng không xóa gì thật.
Kiểm thử có gửi email thật hoặc gọi tích hợp của tôi không?
Không — lưu lượng đi ra được bắt lại, không gửi. Lần chạy ghi rằng email lẽ ra đã được gửi, tới ai và với nội dung gì, và kiểm thử có thể assert trên đó. Khách hàng và công cụ đã kết nối của bạn không bao giờ thấy một kiểm thử.
Tôi thấy gì khi kiểm thử thất bại?
Kết quả theo từng check — file, check, assertion thất bại — cộng với biên nhận tác dụng phụ của lần chạy và lý do từng mục được cho phép hoặc bị từ chối. Cấu trúc đó cho AI chẩn đoán lỗi của chính nó và sửa, thay vì đoán từ một ảnh chụp màn hình.
Kiểm thử có chạy qua quy tắc bảo mật của tôi không?
Có — Scenario chạy với đăng nhập thật trên quy tắc cấp hàng thật, không phải session mock. Nếu một thay đổi cho phép người dùng thấy dữ liệu không thuộc về họ, kiểm thử thất bại trước khi người dùng có thể gặp nó.
Một kiểm thử thất bại có thể chặn bản phát hành không?
Có. Phán quyết Scenario chặn publish — một lần chạy đỏ dừng bản phát hành cho đến khi xanh lại. Cổng chặn là khác biệt giữa hy vọng thay đổi cuối cùng an toàn và biết rằng nó đã được kiểm tra.
Mô tả ứng dụng. Nhận bằng chứng.
Tích hợp sẵn nghĩa là được xây cùng nhau: kiểm thử chạy trên cùng ứng dụng người dùng thấy — nên một kiểm thử checkout thất bại là checkout thất bại, không phải mock.
