Kiểm thử đơn vị xanh không có nghĩa là bạn đã có thể đưa vào vận hành

Chúng tôi bán dịch vụ xác thực, và điều đó biến câu hỏi đáng sợ nhất của chúng tôi thành một câu hỏi rất đơn giản: khi một khách hàng kết nối ứng dụng của họ với chúng tôi và bật mọi thứ lên, liệu nó có thực sự hoạt động, từ đầu đến cuối, trên hệ thống thật hay không? Không phải "các bài kiểm thử đơn vị có chạy qua không", mà là: một tenant hoàn toàn mới có đăng ký được không, có cấu hình SSO và SCIM và MFA và custom claim và thương hiệu, trỏ một ứng dụng thật vào nó, rồi đăng nhập một người dùng thật với đúng các claim trong token, qua một trình duyệt thật. Chúng tôi trả lời câu hỏi đó theo cách duy nhất mà chúng tôi tin tưởng: bằng một bài kiểm thử đầu cuối tự nó trở thành một khách hàng.

Đó là một lần chạy Playwright duy nhất, cố ý tuần tự và có trạng thái, và nó đi qua trọn vẹn vòng đời của một tenant, từ lúc sinh ra cho đến lúc bị xóa. Một tenant đăng ký, được cấu hình đến tận răng, phục vụ một lần đăng nhập thật cho một ứng dụng người dùng thật, được sao lưu rồi khôi phục, rồi tự xóa chính nó. Nếu bất kỳ mắt xích nào trong chuỗi đó đứt, lần chạy chuyển sang đỏ, và chúng tôi không phát hành.

Nó cấu hình mọi thứ, không phải một lát cắt theo đường đi suôn sẻ

Phần giữa của bài kiểm thử kỹ lưỡng một cách có chủ đích. Nó không chỉ đăng nhập rồi xong; nó đi qua từng màn hình mà một người triển khai thật sẽ chạm tới và vận hành chúng một cách thực sự: một client OIDC tùy chỉnh với các URI chuyển hướng và thiết lập token của nó, một scope tùy chỉnh phát ra các claim của người dùng, các vai trò và một phép gán vai trò, một người dùng cuối với một thuộc tính tùy chỉnh, một nhóm với thành viên thật và một ánh xạ nhóm-sang-vai-trò, các kết nối doanh nghiệp SAML và OIDC, một token cấp phát SCIM, một tên miền tùy chỉnh, một ứng dụng cấp phát đi ra, một đồng đội được mời rồi đổi vai trò, thanh toán qua một lần thanh toán thật, nhật ký kiểm toán với các bộ lọc và một bản xuất CSV, một môi trường sandbox, và các thiết lập bảo mật, webhook cùng email (mỗi cái đều được bật chuyển, rồi đưa về trạng thái an toàn). Mỗi một trong số đó đều được tạo, kiểm chứng và, ở nơi hợp lý, xóa đi, trong cùng một lần chạy.

Mục đích không phải là đánh dấu vào ô. Một khách hàng không bao giờ dùng một tính năng đơn lẻ; họ dùng một tổ hợp, và tổ hợp chính là nơi mọi thứ lặng lẽ hỏng. Một custom claim chỉ có ý nghĩa nếu nó xuất hiện trong token được phát ra. Một ánh xạ nhóm-sang-vai-trò chỉ có ý nghĩa nếu vai trò đáp xuống đúng vào khoảnh khắc token được đúc ra. Cách duy nhất để biết là dựng nên toàn bộ rồi đi dùng nó.

Điệu nhảy của thông tin xác thực

Đây là phần khiến một bài kiểm thử đầu cuối cho một sản phẩm xác thực thật sự khó xử: thông tin xác thực không tồn tại khi bài kiểm thử bắt đầu. Bạn không thể viết cứng một client secret hay một token SCIM, bởi vì toàn bộ điểm mấu chốt là tenant tự đúc chúng ra, mới tinh, trong lúc chạy.

Vì vậy bài kiểm thử làm đúng những gì một người triển khai thật làm, chỉ là nhanh hơn. Nó tạo client OIDC trong portal rồi đọc lại client id và secret. Nó đúc một thông tin xác thực Portal API chỉ bằng một cú nhấp và bắt lấy nó. Nó sinh ra một token SCIM. Rồi nó nạp từng cái secret vừa mới đúc đó vào ứng dụng người dùng mẫu đang chờ sẵn, viết lại cấu hình của ứng dụng đó với các giá trị mới, triển khai nó, và chỉ khi đó mới điều khiển lần đăng nhập thực sự. Thông tin xác thực sinh ra ở một bước được tiêm vào ứng dụng đang kiểm thử ở bước kế tiếp, và trình duyệt hoàn tất một lần chuyển hướng OIDC thật dựa trên chúng. Phần tích hợp là một mục tiêu di động mà bài kiểm thử liên tục tự ngắm lại vào chính nó khi nó dần thành hình.

Ứng dụng người dùng đó là một triển khai thật, không phải bản mock. Khi bài kiểm thử xác minh một lần đăng nhập, một ứng dụng thật đã thực sự chuyển hướng đến issuer của tenant, thực sự nhận lại một mã, thực sự đổi nó, và bài kiểm thử giải mã token thu được để xác nhận rằng custom claim và vai trò đã ánh xạ thực sự nằm trong đó. Rồi nó đẩy tới những mép khó hơn: một trang đăng nhập mang thương hiệu tùy chỉnh nằm sau công tắc bật của nó, và một webhook bắt buộc phải chặn một lần đăng nhập mà chính sách từ chối. Một bài kiểm thử xanh ở điểm cuối này có nghĩa là đường từ chối hoạt động, đó là kết quả mà bạn muốn chắc chắn nhất.

Đa yếu tố, một cách thực sự

Một lần đăng nhập bằng mật khẩu tự nó chứng minh được rất ít. Lần chạy đăng ký rồi sau đó sử dụng một bộ xác thực TOTP và một thông tin xác thực WebAuthn thông qua một bộ xác thực ảo, để yếu tố thứ hai được vận hành theo đúng cách của một người dùng thật, chứ không bị thay bằng bản giả.

Phần nửa mà ai cũng bỏ qua: lấy lại được nó

Hầu hết các bài kiểm thử đầu cuối dừng lại ở "nó chạy được". Bài của chúng tôi đi tiếp vào những phần mà bạn chỉ nghĩ tới lúc 2 giờ sáng. Nó tạo một bản sao lưu, xóa dữ liệu của tenant ngay dưới chân chính nó, khôi phục từ bản sao lưu đó, và kiểm chứng rằng cấu hình cùng người dùng đã trở về nguyên vẹn. Rồi nó chạy một lần tự xóa toàn bộ tenant một cách sạch sẽ và tự phục vụ. Một lần chạy không để lại gì phía sau, đó cũng chính là cách chúng tôi biết rằng việc hủy cấp phát thực sự hủy cấp phát.

Vì sao đây là bài kiểm thử mà chúng tôi tin tưởng

Một bức tường kiểm thử đơn vị xanh nói cho bạn biết rằng các hàm của bạn đúng. Bài này nói cho bạn biết rằng một khách hàng có thể bước vào, dựng nên phần tích hợp mà họ thực sự muốn, với những tính năng bảo mật mà họ thực sự cần, và rằng chúng tôi có thể mất dữ liệu của họ rồi trao lại. Đó là sự khác biệt giữa "mã đúng" và "chúng tôi có thể đưa vào vận hành".

Mọi tính năng mà lần chạy này vận hành (SSO và SAML, SCIM, MFA, custom claim và scope, thương hiệu, webhook bắt buộc, xuất kiểm toán) đều có trong sản phẩm ở mọi gói, không bị khóa sau một lần bán thêm gói doanh nghiệp. Xem những gì được bao gồm.