Why isn't all test automation run on the pipeline?

Slalom Build · 2019 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Bài quan điểm của một kỹ sư tư vấn, minh hoạ bằng bốn ca khách hàng ẩn danh. Nhận định là theo tác giả (Slalom).

Bối cảnh

Unit test đã chạy trong mọi pipeline, nhưng test API, UI, tích hợp, module thường vẫn chạy tay trên laptop. Theo tác giả, lý do quy về ba thứ: giá trị (chưa ai tin đáng làm), kiến trúc (hệ không chia module) và khả thi (không gọi được contract của module hay giả được dependency trong test runner).

Phân tầng: module test chạy trong process với dependency được giả (test double), chặn merge ở nhánh feature; site integration test chạy sau khi deploy lên một môi trường có dependency thật, chỉ chứng minh các module ghép với nhau được, và quyết định có đẩy lên môi trường cao hơn hay không. Khuyên mỗi module một repo.
Bốn ca:
1. Test API chạy tay vì không có cách chạy service trong test runner. Gộp SpringRunner với runner DataProviderRunner đang dùng thành một runner, dùng @SpringBootTest, rồi đưa vào pipeline. Khoảng một ngày công, chi phí chạy thêm 0 USD vì runner còn dư capacity.
2. Chỉ có UI site test, chạy tay; runner không được cài browser theo chính sách. Dựng Jenkins trên một VM có Chrome, chạy theo trigger và lịch, gia cố test cho trạng thái site thay đổi. Chi phí một VM cộng khoảng một ngày dựng.
3. Test API site chạy tay vì database "khó giả". Dùng database in-memory của Hibernate (ba dòng cấu hình), biến site test thành module test chạy trong pipeline; khác database thật nhưng vẫn đáng.
4. Ứng dụng desktop nguyên khối đa luồng, có UI test trên pipeline nhưng sửa đâu vỡ đó. Refactor thành module storage, business logic, background, UI, giữ UI test làm lưới an toàn và thêm module test; mất khoảng hai tháng.

Lỗi bắt ở nguồn rẻ nhất, developer ít bị kéo về việc cũ. Khi test không chạy trong pipeline, tester liên tục vá test vỡ và thành "ném qua tường"; theo tác giả, bắt đầu dự án với mọi test trong pipeline dễ hơn đưa vào sau.

Rào cản thường là khả thi kỹ thuật nhỏ (runner, browser, DB giả) chứ không phải chi phí; mỗi ca chỉ tốn khoảng một ngày.
Kiến trúc không có module thì không có module test; refactor có lưới UI test là đường ra, nhưng là phần đắt nhất.
Giả dependency đánh đổi độ giống production lấy khả năng chạy mỗi lần merge; phần còn lại để cho test sau deploy.