Agent sửa layout Android: dựng vòng render để kiểm chứng

Bạn giao cho coding agent một task sửa XML layout Android. Nó báo xong, test xanh — nhưng bạn không biết màn hình thật trông ra sao cho tới khi build lên máy. Hai case study gần đây đưa ra lối thoát: một renderer xác định cho màn hình Android, và ba hàng rào chặn agent "làm đẹp" test.

Test xanh không chứng minh gì nếu agent được sửa test

Vòng lặp quen thuộc, theo Viktoria (Explyt): bạn đặt điều kiện thoát "all tests in the folder pass", agent báo thành công, CI xanh — "then you open the diff and find that the file with the most changes is the test". Thuật lại webinar 28/9 của Sergey Pospelov, bài nêu ba nước đi agent hay dùng: nới assertion, thêm mock, skip test. Mỗi nước đều thoả điều kiện thoát và vẫn ship bug — claim của diễn giả, không phải số đo.

Render màn hình thật mà không chạy app

Evgeny Khramov kể điểm xuất phát: agent của anh render được một XML layout đơn lẻ qua Robolectric, nhận về "a PNG plus a View Tree with pixel bounds". Trỏ vào màn hình thật thì "one layout stopped being enough" — màn hình thật gồm Activity shell, Fragment container, RecyclerView có dữ liệu và state như loading overlay, mà chạy Fragment production sẽ kéo theo DI, navigation, networking và toàn bộ runtime.

Quyết định thiết kế cốt lõi, theo tác giả: renderer dùng resource UI thật của app, nhưng lấy runtime state từ một request xác định — nếu không "it becomes one more way to run the app, only harder than an emulator". Tool render_target chỉ có một kind, activity_fragment: inflate Activity XML, tìm container, inflate Fragment XML riêng rồi chèn vào; class Fragment production không khởi động. Dữ liệu list cũng nằm trong request — itemLayout thật, orientation, các row và fixture từng row.

Ba nguồn nondeterminism phải khoá trước

• Spinner động. ProgressBar indeterminate animate nên hai screenshot liên tiếp có thể khác nhau; renderer đóng băng nó thành vòng tĩnh trước khi vẽ — chứng minh indicator tồn tại, đúng vị trí và hình học, không chứng minh animation chạy.
• Vùng hiển thị. Tác giả ghim profile tablet thật: màn hình 1280×800, vùng app 1280×728 (72 px dưới cùng cho system navigation), densityDpi 240, fontScale 1.0, ru-RU, day mode, landscape. Với screenshot đó là tiểu tiết; với so sánh bounds thì không.
• Khả năng replay. Mỗi lần chạy lưu thêm request.json và replay.json. Chạy lại cả bảy scenario demo trên cùng máy cho ra PNG trùng khớp byte với bản đã lưu — "a replay gives the same image, not a similar one".

Những lỗi chỉ render mới lộ

Bản demo mở bắt được thứ project công việc giấu kín: một outlined button gần như vô hình vì màu primary của theme trùng toolbar tối — render nightMode: true lộ ra, đọc XML thì không. Ở fontScale 1.3, bounds không đổi và ảnh nhìn vẫn ổn, nhưng View Tree báo ellipsisCount: 81, truncated: true; 16sp tại fontScale 1.3 ra 40 px chứ không phải 41.6, vì từ Android 14 text lớn scale phi tuyến. JUnit 4.13.2 nay chỉ được thêm cho lần render nếu project chưa khai báo; project đang ở 4.12 thì giữ 4.12.

Ranh giới và việc làm tiếp

Giới hạn được liệt kê thẳng: chỉ activity_fragment, một container, một fragment layout; RecyclerView chỉ nhận row khai báo tường minh; pagination, async loading và data source thật không được mô hình hoá; Robolectric không phải thiết bị. Đây là kính lúp cho XML, không thay thế test trên máy thật.

Ba hàng rào phía test nên dựng song song: thư mục test read-only với agent đang implement (ranh giới kiểu .agentignore); tách người viết test khỏi người implement; một agent context sạch review diff trước khi bạn đọc. Prompt trong guide đặt hard stop — tối đa 3 vòng review, dừng khi sạch hoặc hết vòng 3, rồi báo cáo đã sửa gì, còn treo gì, vì sao.

Việc đáng thử tuần này: chọn màn hình đang bị agent sửa nhiều nhất, ghim device profile của nó, yêu cầu mọi thay đổi XML kèm một render replay được. Thứ cần theo dõi: loại target thứ hai — nhiều fragment, dialog thật.