Một học viên lớp DevOps nhắn tin cho tôi "Anh Cường, em không hiểu tại sao trong khoá học DevOps, mà bọn em phải lập trình kiểm thử là sao nhỉ. Em muốn được học về Kubernetes, AWS nhiều hơn". Rõ ràng là một câu hỏi rất thực dụng và đúng chất của một lập trình viên: rất thích công nghệ mới hot trend, và tránh công việc kiểm thử càng nhiều càng tốt.

Tuy nhiên kiểm thử tự động là một bước quan trọng trong cả quy trình CI/CD. Thử hình dùng mọi bước trong quy trình CI/CD đều được tự động, chạy rất nhanh, nhưng khi đến bước kiểm thử, phải mất vài ngày để kiểm tra chất lượng sản phẩm, toàn bộ quy trình sẽ bị ách tắc tại đây. Do đó để CI/CD vận hành đúng, cần có nhiều kịch bản kiểm thử tự động ở nhiều thành phần của sản phẩm để cải tiến chất lượng.

End to End Testing khác gì với Unit Testing

Ngày hôm nay, vận hành của một web site phức tạp hơn rất nhiều trước đây. Giao diện web sẽ kết nối tới một dịch vụ REST. Dịch vụ này có thể gọi tiếp đến nhiều dịch vụ REST hoặc gRPC phía sau. Nếu chỉ kiểm thử từng dịch vụ REST thì chưa đủ, và không đảm bảo giao diện hoạt động theo đúng ý người dùng. Do đó End to End Testing sẽ rất hữu ích đảm bảo trải nghiệm sử dụng được chức năng ứng dụng thay vì quá mất nhiều thời gian để viết unit test từng dịch vụ REST API. Tối ưu nhất là chúng ta viết đầy đủ Unit Test và End to End Test. Nhưng nếu do nguồn lực có hạn, thì nên ưu tiên viết End to End Test trước.

Tích hợp End to End Test vào CI/CD như thế nào?

Khi bạn xây dựng một quy trình CI/CD, bạn cần nhúng End to End Test vào thành một bước trong kịch bản CI/CD. Ví dụ: sau khi deploy xong, cần tiến hành End to End Testing sau đó xuất ra báo cáo kết quả. Gửi kết quả vào email đội lập trình chả hạn.
Về bản chất đấy chỉ là việc thực thi câu lệnh chạy CodeCept.io trong bash shell. 

Dưới đây là link tham khảo mẫu code tích hợp CodeCept với GitLab CI, Jenkins, TeamCity
https://codecept.io/continuous-integration/