Bỏ qua tới nội dung
Kiên

Test những cái booking tiêu tiền thật

· 4 phút đọc

Ở phần lớn hệ thống, kết cục đắt nhất của một bài test là màu đỏ. Ở hệ thống booking thì là màu xanh — test pass nghĩa là vừa đặt một thứ có thật. Cách để vẫn test được trọn luồng: một luật chọn offer kiêm luôn cơ chế an toàn, và một gói bằng chứng — chứ không phải dấu tích xanh — làm thứ đối tác thật sự ngồi review.

  • testing
  • tích hợp
  • QA
  • bằng chứng
Mục lục
  1. Trọn luồng, đi qua cửa chính
  2. Luật chọn offer chính là cơ chế an toàn
  3. Certification là một cái thư mục, không phải một dấu tích
  4. Mỗi cú fail là một cái curl
  5. Những con số mình không có
  6. Cái artifact mới là trọng tâm

Ở phần lớn hệ thống, thứ bạn phải phòng bị là bộ test đỏ. Ở hệ thống booking thì là bộ test xanh: một bài test trọn luồng mà pass nghĩa là nó vừa giữ chỗ một thứ trong kho hàng thật, dưới một tài khoản thật, kèm một chính sách huỷ thật.

Mấy câu trả lời tiêu chuẩn đều không vừa. Mock supplier thì bạn đang test cái mock — thứ thật sự vỡ trong nghề này là cuộc hội thoại với bên kia, không phải mấy lời gọi hàm của chính bạn. Trỏ vào sandbox của supplier thì bạn đang test cái sandbox, mà sandbox có bug riêng, kho hàng riêng, và một quan niệm riêng về giá trông như thế nào. Đến một lúc nào đó, cái luồng phải chạy thật — và "thật" nghĩa là chạy xong thì tồn tại một cái booking.

Trọn luồng, đi qua cửa chính

Bộ test trọn luồng chạy qua HTTP API công khai, dưới danh nghĩa một test user trên staging: login → search → search-by-id → prebook → book → cancel. Đúng cái cửa mà đối tác đi, đúng contract đó, đúng thứ tự gọi đó — không phải một bộ harness câu thẳng vào ruột hệ thống. Nếu cái luồng chỉ chạy được khi đi cửa sau, thì coi như nó không chạy được.

Bước cuối không phải màn dọn dẹp gắn thêm vào cho sạch. Cancel là một phần của cái luồng đang được test, vì nó là một phần của sản phẩm: một đối tác book qua bạn được mà huỷ qua bạn không được thì đang gặp chuyện lớn hơn nhiều so với một lượt test fail.

Luật chọn offer chính là cơ chế an toàn

Đây là phần mình thấy đẹp thật sự, và nó gói trong một câu: bài test luôn chọn offer rẻ nhất có miễn phí huỷ.

Cái luật đó không phải một sở thích, nó là toàn bộ mô hình an toàn. Một cái booking thành công có thể được tháo ra với chi phí bằng 0 — book, verify, cancel, và sổ sách ghi con số 0. Không có cờ sandbox, không có "test mode" nào phải trông chờ supplier tôn trọng, không có con job dọn dẹp đi quét những chỗ giữ bị bỏ quên. Sự an toàn nằm ở thứ mà bài test chọn mua.

Mình thích nó vì đó là rào chắn đặt trong tool chứ không đặt trong đầu người — cùng một nguyên tắc với mọi quy trình ghi trên site này. Không ai phải nhớ chọn rate hoàn được tiền lúc 11 giờ đêm; cái bộ chọn không thể chọn thứ gì khác.

Nó có cái giá của nó, và phiên bản trung thực của bài này phải gọi tên ra: luật đó nghĩa là cái luồng chỉ luôn đi qua góc rẻ nhất, huỷ-được-miễn-phí của kho hàng. Rate không hoàn tiền, phân khúc đắt, mấy chính sách huỷ oái oăm — bài test trọn luồng không bao giờ chạm tới, ngay từ cách nó được dựng. Cái lỗ hổng coverage đó là có thật, và nó là giá phải trả để bài test chạy được ngay từ đầu.

Certification là một cái thư mục, không phải một dấu tích

Tích hợp một supplier mới kết thúc bằng certification, và certification là chỗ cái triết lý lộ ra rõ nhất. Nó chạy một catalog testcase riêng cho từng provider qua trọn cái luồng — search → xác nhận giá → PNR/booking → retrieve → cancel — và với từng testcase, request/response thô cộng với đúng cái lời gọi bắn lên thượng nguồn được gom về một thư mục có tên riêng.

Cái thư mục đó — gói bằng chứng — mới là sản phẩm bàn giao. Không phải cái lượt chạy xanh đã sinh ra nó. Đối tác ngồi review cái gói, vì cái gói là vật duy nhất trả lời được đúng câu hỏi của họ. Một dấu tích xanh khẳng định "code của tôi trả về đúng thứ assertion của tôi mong đợi" — đó là một khẳng định về code của mình. Câu hỏi của đối tác là "anh đã gọi API của tôi đúng chưa, trong những kịch bản này, và nó trả lời lại cái gì?" — và thứ duy nhất trả lời được là chính những byte đã chạy qua dây.

Mỗi cú fail là một cái curl

Log của provider được giữ ở dạng chạy lại được: một case fail có thể được bắn lại bằng đúng cái curl đã gửi đi. Chuyện này quan trọng vì debug tích hợp thực chất chỉ là một câu hỏi lặp đi lặp lại — mình gửi sai, hay bên kia trả lời sai? Một dòng log tóm tắt cú fail không phân xử được câu đó. Đúng cái request ấy, bắn lại trong cô lập, phân xử nó trong một bước — và biến "retry thì chạy, chịu không hiểu vì sao" từ một cái nhún vai thành một case tái hiện được.

Những con số mình không có

Mình chưa đếm bộ test đã book trọn luồng bao nhiêu lần, và cũng chưa ai tính thử nếu không có luật rẻ-nhất-miễn-phí-huỷ thì các lần huỷ đã tốn bao nhiêu — theo cách dựng thì con số đó phải bằng 0, nhưng "bằng 0 theo cách dựng" là một khẳng định thiết kế, không phải một số đo, và mình dán nhãn nó đúng như vậy.

Cái artifact mới là trọng tâm

Chủ đề nằm dưới tất cả: trong test tích hợp, artifact chính là gói bằng chứng. Một bộ test xanh mà không có artifact là một lời khẳng định chưa được kiểm chứng — bạn đang đề nghị người đọc tin rằng những lời gọi đúng đã xảy ra, đúng thứ tự, đúng payload, chỉ vì một cái bit lật sang true. Có cái gói thì không ai phải tin ai cả: cuộc hội thoại nằm trên đĩa, có tên, chạy lại được, và review được bởi đúng cái bên quan tâm nhất mà cũng ít tin mình nhất.

Màu xanh là bản tóm tắt. Cái thư mục mới là bằng chứng.

Bài liên quan

· 5 phút đọc

"Tức là gọi API của người khác hả" — câu tóm tắt mình nghe nhiều nhất về công việc của mình, và nó sai theo một cách đáng để mổ xẻ. Khoảng 150 supplier code trên chừng 90 tích hợp, hai pattern offer được ghi thành tài liệu, hai mô hình thực thi sau cùng một contract, và những supplier trả 200 kèm lỗi bên trong — một vòng quanh việc này thật sự gồm những gì, và vì sao nó là kiến trúc.

  • tích hợp
  • kiến trúc
  • API design
  • hệ phân tán

· 5 phút đọc

Ngày đầu với một supplier mới, mình không viết dòng code nào. Có một danh sách câu hỏi cố định — auth và cách xoay credential, search một nhịp hay hai nhịp, offer có định danh gì và sống được bao lâu, book có idempotent không và nếu không thì tra bằng gì, lỗi nằm ở đâu, chính sách có cấu trúc không, mô hình rate ngụ ý pattern nào — và các câu trả lời quyết định hình dạng của module. Con số ước lượng đi ra từ lượt đọc đó, không đi ra từ số endpoint.

  • tích hợp
  • API design
  • phương pháp
  • ước lượng