Google Espresso hoặc Robotium [đã đóng cửa]

Tôi phải sử dụng công cụ kiểm tra giao diện người dùng tự động và tôi đang phân vân giữa việc sử dụng Robotium và Google Espresso.

Sự khác biệt chính giữa hai là gì? Có những tính năng nào tồn tại trong cái này mà không tồn tại ở cái kia không?

Tiết lộ đầy đủ: Tôi là một trong những tác giả của Espresso.

Cả Espresso và Robotium đều là các khuôn khổ dựa trên thiết bị đo, có nghĩa là chúng sử dụng Android Instrumentation để kiểm tra và tương tác với các Hoạt động đang được thử nghiệm.

Tại Google, chúng tôi bắt đầu bằng cách sử dụng Robotium vì nó tiện lợi hơn so với thiết bị đo đạc cổ phiếu (xin cảm ơn các nhà phát triển Robotium đã làm như vậy). Tuy nhiên, nó không đáp ứng được nhu cầu của chúng tôi về một khuôn khổ giúp các nhà phát triển dễ dàng viết các bài kiểm tra đáng tin cậy .

Những tiến bộ lớn trong Espresso so với Robotium:

1. Đồng bộ hóa. Theo mặc định, logic kiểm tra thiết bị chạy trên một luồng (thiết bị đo đạc) khác với các hoạt động giao diện người dùng (được xử lý trên luồng giao diện người dùng). Nếu không đồng bộ hóa các hoạt động kiểm tra với các bản cập nhật giao diện người dùng, các bài kiểm tra sẽ dễ bị bong tróc - tức là sẽ thất bại ngẫu nhiên vì các vấn đề về thời gian. Hầu hết các tác giả thử nghiệm bỏ qua thực tế này, một số thêm cơ chế ngủ / thử lại và thậm chí ít triển khai mã an toàn luồng phức tạp hơn. Không ai trong số này là lý tưởng. Espresso quan tâm đến an toàn luồng bằng cách đồng bộ hóa liền mạch các hành động thử nghiệm và xác nhận với giao diện người dùng của ứng dụng đang thử nghiệm. Robotium cố gắng giải quyết vấn đề này bằng các cơ chế ngủ / thử lại, cơ chế này không chỉ không đáng tin cậy mà còn khiến các bài kiểm tra chạy chậm hơn mức cần thiết.

2. API. Espresso có một API nhỏ, được xác định rõ ràng và có thể dự đoán được, có thể tùy chỉnh. Bạn cho khung công tác biết cách xác định vị trí một phần tử giao diện người dùng bằng cách sử dụng các trình so khớp hamcrest tiêu chuẩn và sau đó hướng dẫn nó thực hiện một hành động hoặc kiểm tra xác nhận trên phần tử đích. Bạn có thể đối chiếu điều này với API của Robotium, nơi tác giả thử nghiệm dự kiến ​​sẽ chọn từ hơn 30 phương pháp nhấp chuột. Hơn nữa, Robotium tiết lộ các phương thức nguy hiểm như getCurrentActivity (hiện tại có nghĩa là gì?) Và getView, cho phép bạn hoạt động trên các đối tượng bên ngoài luồng chính (xem điểm ở trên).

3. Xóa thông tin lỗi. Espresso cố gắng cung cấp thông tin gỡ lỗi phong phú khi xảy ra lỗi. Hơn nữa, bạn có thể tùy chỉnh cách xử lý lỗi của Espresso bằng trình xử lý lỗi của riêng bạn. Tôi đã không thử nó trong một thời gian, nhưng các phiên bản trước của Robotium bị lỗi xử lý không nhất quán (ví dụ: phương thức clickOnView sẽ nuốt SecurityExceptions).

Trái ngược với câu trả lời trước đó, Espresso được hỗ trợ trên tất cả các phiên bản API với số lượng người dùng đáng kể (xem: http://developer.android.com/about/dashboards/index.html ). Nó hoạt động trên một số phiên bản cũ hơn, nhưng thử nghiệm trên những phiên bản đó sẽ rất lãng phí tài nguyên. Nói về thử nghiệm ... Espresso được kiểm tra mọi thay đổi bằng bộ thử nghiệm toàn diện (với độ phủ hơn 95%) cũng như phần lớn các ứng dụng Android do Google phát triển.

Espresso nhanh hơn nhiều so với Robotium, nhưng chỉ hoạt động trên một số phiên bản SDK.

Vì vậy, nếu bạn muốn một bài kiểm tra hoạt động trên tất cả các thiết bị, hãy sử dụng Roboitum. Nếu không, hãy thưởng thức cà phê espresso, và đừng quên rằng bạn sẽ là người thử nghiệm bản beta trong một thời gian nữa.