- Trong bài báo "Automated Unit Test Improvement using Large Language Models at Meta" mà Meta công bố vào tháng 2, một công cụ tên là TestGen-LLM đã được giới thiệu
- Mục tiêu của công cụ này là tăng độ bao phủ kiểm thử theo cách hoàn toàn tự động, đồng thời đảm bảo kết quả được cải thiện so với codebase hiện có
- Vì Meta không công bố mã nguồn của TestGen-LLM, nhóm tác giả đã quyết định tự hiện thực nó như một phần của dự án mã nguồn mở Cover Agent
- Bài viết này chia sẻ quá trình hiện thực, những điều đã phát hiện, cũng như các vấn đề gặp phải khi sử dụng TestGen-LLM trên codebase thực tế
Tiêu chí cho việc tạo kiểm thử tự động
- Việc tạo kiểm thử tự động bằng AI tạo sinh không phải là điều mới
- Hầu hết các LLM đều giỏi sinh mã và cũng có thể sinh kiểm thử
- Vấn đề phổ biến nhất mà các lập trình viên gặp phải khi dùng LLM để tạo kiểm thử là phần lớn kiểm thử được sinh ra либо không chạy được, либо không mang lại giá trị gì thêm
- Để khắc phục điều này, các tác giả của TestGen-LLM đã đưa ra các tiêu chí sau cho kiểm thử đơn vị hồi quy:
- Kiểm thử có biên dịch và chạy đúng hay không?
- Kiểm thử có làm tăng độ bao phủ mã hay không?
- Nếu không trả lời được hai câu hỏi cơ bản này, thì không có lý do gì để chấp nhận hoặc phân tích các kiểm thử do LLM tạo ra
- Nếu vượt qua được các câu hỏi này, bước tiếp theo sẽ là rà soát thủ công
- Kiểm thử được viết tốt đến mức nào?
- Nó thực sự có thể bổ sung bao nhiêu giá trị?
- Nó có đáp ứng các yêu cầu bổ sung hay không?
Cách tiếp cận của TestGen-LLM và kết quả được báo cáo
- TestGen-LLM (và Cover-Agent) chạy hoàn toàn ở chế độ headless
- Trước tiên hệ thống sinh ra nhiều kiểm thử, sau đó lọc bỏ những kiểm thử không build/chạy được, loại những kiểm thử không pass, và loại bỏ những kiểm thử không làm tăng độ bao phủ mã
- Trong các trường hợp được kiểm soát chặt chẽ, tỷ lệ kiểm thử được sinh ra so với số kiểm thử vượt qua mọi bước là 1:4, còn trong các tình huống thực tế, các tác giả của Meta báo cáo tỷ lệ 1:20
- Sau quy trình tự động, Meta để người đánh giá là con người chấp nhận hoặc từ chối kiểm thử
- Các tác giả bài báo cho biết trong trường hợp tốt nhất, tỷ lệ chấp nhận đạt 73%, với tỷ lệ chấp nhận trung bình là 1:2
- Như được mô tả trong bài báo, công cụ TestGen-LLM sẽ tạo ra một kiểm thử đơn lẻ trong mỗi lần chạy để bổ sung vào test suite hiện có vốn đã được các lập trình viên chuyên nghiệp viết từ trước
- Ngoài ra, nó cũng không nhất thiết phải tạo ra kiểm thử cho mọi test suite được đưa vào
Hiện thực Cover-Agent
- Cover-Agent v0.1 được hiện thực như sau:
- Nhận đầu vào từ người dùng (file mã nguồn cần kiểm thử, test suite hiện có cần cải thiện, báo cáo độ bao phủ, lệnh build và chạy test suite, mục tiêu độ bao phủ mã và số lần lặp tối đa, ngữ cảnh bổ sung và các tùy chọn prompt)
- Sinh thêm các kiểm thử theo cùng một phong cách
- Xác thực các kiểm thử đó bằng môi trường runtime (có build được và pass hay không)
- Xem xét các chỉ số như mức tăng độ bao phủ mã để xác định liệu kiểm thử có mang lại giá trị hay không
- Cập nhật test suite hiện có và báo cáo độ bao phủ
- Lặp lại cho đến khi mã đạt tiêu chí (đạt ngưỡng độ bao phủ mã hoặc chạm số lần lặp tối đa)
Các vấn đề gặp phải khi hiện thực và đánh giá TestGen-LLM
- Trong ví dụ được nêu trong bài báo, Kotlin được dùng để viết kiểm thử, nơi khoảng trắng không quan trọng
- Trong khi đó, ở các ngôn ngữ như Python, tab và khoảng trắng không chỉ quan trọng mà còn là yếu tố thiết yếu đối với bộ phân tích cú pháp
- Các mô hình kém tinh vi hơn như GPT 3.5, ngay cả khi được prompt rõ ràng, vẫn không nhất quán trong việc trả về mã có thụt lề đúng
- Một ví dụ gây ra vấn đề là các lớp kiểm thử viết bằng Python, nơi mỗi hàm kiểm thử đều phải được thụt lề
- Điều này phải được tính đến trong toàn bộ vòng đời phát triển, và làm tăng thêm độ phức tạp xung quanh thư viện tiền xử lý
- Vẫn còn nhiều điểm cần cải thiện để Cover-Agent trở nên vững chắc trong các tình huống như vậy
- Nhóm đã bổ sung khả năng để người dùng cung cấp thêm đầu vào hoặc chỉ dẫn cho LLM như một phần của luồng Cover-Agent (tùy chọn
--additional-instructions)
- Nhờ đó, lập trình viên có thể tùy biến Cover-Agent bằng cách cung cấp thêm thông tin đặc thù của dự án
- Ví dụ, có thể dùng các chỉ dẫn này để hướng Cover-Agent tạo ra một bộ kiểm thử phong phú với các edge case có ý nghĩa
- Đồng thuận với xu hướng chung là Retrieval-Augmented Generation (RAG) ngày càng phổ biến hơn trong các ứng dụng AI, nhóm cũng xác nhận rằng việc có thêm ngữ cảnh khi sinh unit test cho phép tạo ra các kiểm thử chất lượng cao hơn và tỷ lệ pass cao hơn
- Để cải thiện quy trình sinh kiểm thử, nhóm cung cấp tùy chọn
--included-files cho những người dùng muốn tự thêm các thư viện bổ sung hoặc tài liệu thiết kế dạng văn bản làm ngữ cảnh cho LLM
- Những đoạn mã phức tạp cần nhiều vòng lặp tiếp tục đặt ra thêm một thách thức cho LLM
- Khi các kiểm thử thất bại (hoặc không mang lại giá trị) được sinh ra, nhóm bắt đầu nhận thấy một mẫu lặp lại: trong các vòng sau, cùng một kiểm thử không được chấp nhận lại tiếp tục được đề xuất
- Để giải quyết điều này, nhóm đã thêm một phần "kiểm thử thất bại" vào prompt để truyền phản hồi đó cho LLM, đồng thời yêu cầu nó tạo ra các kiểm thử độc nhất và tuyệt đối không lặp lại những kiểm thử mà nó đã xác định là không dùng được (tức là bị lỗi hoặc không tăng đủ độ bao phủ)
- Một vấn đề khác nảy sinh trong suốt quá trình này là không thể thêm import thư viện khi mở rộng test suite hiện có
- Các lập trình viên đôi khi có thể thiển cận khi chỉ dùng một cách tiếp cận duy nhất với framework kiểm thử trong quá trình sinh kiểm thử
- Ngoài rất nhiều mocking framework khác nhau, còn có những thư viện khác có thể giúp đạt được độ bao phủ kiểm thử
- Vì bài báo về TestGen-LLM (và Cover-Agent) hướng tới việc mở rộng test suite hiện có, nên việc tái cấu trúc hoàn toàn cả lớp kiểm thử nằm ngoài phạm vi
- Đây là một giới hạn của việc mở rộng kiểm thử so với sinh kiểm thử, và nhóm dự định sẽ giải quyết nó trong các vòng lặp tương lai
- Cần phân biệt rõ rằng trong cách tiếp cận của TestGen-LLM, mỗi kiểm thử đều cần được lập trình viên rà soát thủ công trước khi kiểm thử tiếp theo được đề xuất
- Trong khi đó, Cover-Agent sẽ sinh, xác thực và đề xuất nhiều kiểm thử nhất có thể trong suốt quy trình mà không cần can thiệp thủ công, cho đến khi đạt yêu cầu về độ bao phủ (hoặc dừng ở số vòng lặp tối đa)
- Điều này tạo ra một cách tiếp cận ít gây gián đoạn hơn đối với việc sinh kiểm thử tự động: dùng AI chạy ở hậu trường để lập trình viên có thể rà soát toàn bộ test suite một lần sau khi quy trình hoàn tất
Kết luận và kế hoạch sắp tới
- Nhiều người (bao gồm cả tác giả) đang rất kỳ vọng vào bài báo và công cụ TestGen-LLM, nhưng bài viết này cũng đã nói về những giới hạn của nó
- Nhóm vẫn cho rằng hiện tại chúng ta đang ở thời đại của AI assistant, chứ chưa phải thời đại của một đồng đội AI có thể vận hành một workflow hoàn toàn tự động
- Đồng thời, một luồng được thiết kế tốt vẫn có thể giúp lập trình viên tự động tạo ra các ứng viên kiểm thử và tăng độ bao phủ mã trong thời gian ngắn hơn nhiều, và đó là điều nhóm dự định tiếp tục phát triển và chia sẻ trong Cover-Agent
- Nhóm sẽ tiếp tục phát triển các phương pháp tiên tiến nhất liên quan đến lĩnh vực sinh kiểm thử và tích hợp chúng vào kho mã nguồn mở Cover-Agent
- Nhóm mong tất cả những ai quan tâm đến AI tạo sinh cho kiểm thử sẽ cùng hợp tác, giúp mở rộng khả năng của Cover Agent, và hy vọng công cụ mã nguồn mở này sẽ truyền cảm hứng cho các nhà nghiên cứu khám phá các kỹ thuật sinh kiểm thử mới
- Nhóm đã thêm lộ trình phát triển vào kho mã nguồn mở Cover-Agent trên GitHub, và muốn thấy mọi người đóng góp cho kho theo lộ trình đó hoặc theo những ý tưởng riêng của mình
- Tầm nhìn của Cover-Agent là trong tương lai nó sẽ tự động chạy cho mọi yêu cầu pre/post-pull, và tự động đề xuất các cải tiến kiểm thử hồi quy đã được xác minh là hoạt động tốt và giúp tăng độ bao phủ mã
- Nhóm hình dung Cover-Agent sẽ tự động quét codebase và mở PR với test suite
- Hãy dùng AI để xử lý hiệu quả hơn những công việc mà chúng ta không thích làm!
Chưa có bình luận nào.