Testcontainers - Kiểm thử đơn vị với các phụ thuộc thực tế

• Framework mã nguồn mở cung cấp cơ sở dữ liệu, message broker, trình duyệt web... có thể chạy trong container Docker
• Không cần cấu hình môi trường phức tạp hay đối tượng mô phỏng (mock); bạn định nghĩa các phụ thuộc kiểm thử bằng mã, khi chạy kiểm thử thì container sẽ được tạo và xóa
• Hỗ trợ nhiều ngôn ngữ và framework kiểm thử, có thể bắt đầu chỉ với Docker
• Mô-đun: kiểm thử mọi thứ có thể được container hóa
  • Có thể kiểm thử nhiều thành phần khác nhau thông qua hơn 50 mô-đun như cơ sở dữ liệu, message broker...
• Ngôn ngữ được hỗ trợ: có các bản triển khai Testcontainers cho nhiều ngôn ngữ phổ biến như Java, Go, .NET, Node.js, Python, Rust, Haskell, Ruby, Clojure, Elixir...

Trường hợp sử dụng: Cách Testcontainers có thể giúp ích

• Kiểm thử tích hợp tầng truy cập dữ liệu: kiểm thử mã của tầng truy cập dữ liệu bằng cách sử dụng phiên bản cơ sở dữ liệu đã được container hóa
• Kiểm thử UI/chấp nhận: chạy kiểm thử UI tự động bằng trình duyệt web được container hóa tương thích với Selenium
• Kiểm thử tích hợp ứng dụng: chạy ứng dụng ở chế độ kiểm thử ngắn hạn với các phụ thuộc như cơ sở dữ liệu, hàng đợi thông điệp, máy chủ web... để cung cấp môi trường kiểm thử giàu tương tác và mang tính khám phá

Ý kiến của GN⁺

• Testcontainers giúp các nhà phát triển thực hiện kiểm thử trong những điều kiện tương tự môi trường thực tế, từ đó góp phần nâng cao chất lượng phần mềm.
• Kiểm thử với các phụ thuộc thực tế có thể mang lại kết quả chính xác hơn so với việc dùng đối tượng mô phỏng, nhưng trong các hệ thống phức tạp thì việc thiết lập và quản lý có thể khó khăn.
• Các dự án khác cung cấp chức năng tương tự Testcontainers gồm có Docker Compose, Kubernetes Minikube..., và chúng cũng có thể được dùng như công cụ hỗ trợ kiểm thử trong môi trường phát triển.
• Khi áp dụng Testcontainers, cần có hiểu biết về Docker, đồng thời có thể cần kiến thức kỹ thuật về quản lý container và cấu hình mạng.
• Lợi ích khi chọn công nghệ này là tăng tính nhất quán giữa môi trường phát triển và kiểm thử, đồng thời cải thiện độ tin cậy của kiểm thử; ngược lại, sự phụ thuộc vào môi trường Docker và độ phức tạp liên quan có thể là nhược điểm.

[GN⁺]

Ý kiến trên Hacker News

• Tóm tắt bình luận thứ nhất:

  • Không ngờ Testcontainers lại được ca ngợi đến vậy.
  • Nếu đến từ môi trường không dùng Docker thì nó có thể trông hấp dẫn.
  • Nó hữu ích trong nhiều trường hợp sử dụng, nhưng khó làm cho nó hoạt động tốt với các workflow được container hóa khác.
  • Testcontainers là một thư viện dùng các lời gọi shell tùy biến tới Docker CLI làm chức năng cốt lõi, nên gây ra vấn đề và độ phức tạp khi đưa vào các workflow container hóa khác.
  • Nó có xu hướng giả định rằng chỉ chạy trên máy host và không có tác vụ nào khác liên quan đến Docker, nên thường tệ ngang hoặc thậm chí tệ hơn các thư viện không dùng Docker.

• Tóm tắt bình luận thứ hai:

  • Testcontainers là thứ thay đổi cuộc chơi đối với kiểm thử tích hợp.
  • Nó cung cấp Docker API theo từng ngôn ngữ để dễ dàng khởi chạy container và kiểm tra trạng thái sẵn sàng kết nối.
  • Tôi dùng Testcontainers cho kiểm thử tích hợp trong mọi dự án mới.
  • Cấu hình CI bao gồm linting, build, unit test và kiểm thử tích hợp dùng Testcontainers.
  • Các binding theo ngôn ngữ cung cấp các hàm helper hữu ích cho thao tác với cơ sở dữ liệu.

• Tóm tắt bình luận thứ ba:

  • Không hiểu vì sao dùng docker-compose.yml lại không tốt hơn.
  • Testcontainers khá yếu khi có các phụ thuộc phức tạp giữa những container cần thiết.
  • Tôi đã dùng nó khoảng 5 năm trước, nhưng bây giờ có thể tình hình đã cải thiện nhiều.

• Tóm tắt bình luận thứ tư:

  • Rất coi trọng các bài kiểm thử tích hợp dùng cơ sở dữ liệu/Elasticsearch/Redis/Varnish thật.
  • Testcontainers giúp xử lý các việc như tạo chỉ mục Elasticsearch mới trong suốt bộ test rồi dọn dẹp khi kết thúc.
  • Tôi thích chiến lược bao phủ càng nhiều chức năng ứng dụng càng tốt bằng các bài test kiểu tích hợp end-to-end.
  • Chỉ dùng unit test cho những phần mã có cặp đầu vào/đầu ra rõ ràng, và dùng mock cho các lời gọi API bên ngoài không thể kiểm soát.

• Tóm tắt bình luận thứ năm:

  • Khoảng 7 năm trước, tôi đã viết conex, một Testcontainers cho ngôn ngữ Go.
  • Nó cung cấp tích hợp hạng nhất với framework test chính thức của Go.

• Tóm tắt bình luận thứ sáu:

  • Có ý kiến cho rằng việc cung cấp một instance trình duyệt mới, sạch cho mỗi bài test là chậm.
  • Nếu đã đầu tư vào thế giới container thì nên chấp nhận thêm vài container nữa.
  • Nếu không, lợi ích nhận được là không nhiều so với độ phức tạp hay sự cồng kềnh bổ sung.

• Tóm tắt bình luận thứ bảy:

  • Tôi đã xem qua Testcontainers rồi tự làm một phiên bản riêng.
  • Docker là một lớp trừu tượng bị rò rỉ và bạn phải chạy test trong nhiều môi trường khác nhau.
  • Mạng hoạt động hoàn toàn khác nhau trên Mac, Linux VM, hay bên trong container Docker trên Linux VM với socket Docker được mount vào.
  • Tôi muốn chạy test song song và in log phù hợp cho từng bài test.
  • Tôi không chắc Testcontainers đã giải quyết được các vấn đề này chưa, nhưng đã nhận ra rằng chi tiết mới là thứ quyết định tất cả.

• Tóm tắt bình luận thứ tám:

  • Tôi tạo môi trường test cục bộ bằng docker-compose.
  • Testcontainers có vẻ là một lớp trừu tượng bằng ngôn ngữ lập trình để định nghĩa môi trường Docker mà không cần học cú pháp của Docker Compose.
  • Để biết môi trường test đã sẵn sàng sử dụng hay chưa, bạn vẫn cần hiểu về Docker networking, dependency và healthcheck.

• Tóm tắt bình luận thứ chín:

  • Không cần mock hay cấu hình môi trường phức tạp.
  • Định nghĩa các dependency của test bằng mã rồi chạy test, container sẽ được tạo ra và xóa đi.
  • Nghĩ rằng có thể chạy kiểm thử tích hợp bằng container thì không cần unit test nữa là một sự hiểu lầm.
  • Việc cấu hình container Docker thì đơn giản, nhưng khởi động container lại đau đớn và chậm.

• Tóm tắt bình luận thứ mười:

  • Đây là câu hỏi về việc dùng Duke làm logo của Java.