Làm cách nào tôi có thể kiểm tra đơn vị GUI?

Các tính toán trong mã của tôi được kiểm tra tốt, nhưng vì có quá nhiều mã GUI, nên độ bao phủ mã tổng thể của tôi thấp hơn tôi muốn. Có hướng dẫn nào về mã GUI kiểm thử đơn vị không? Nó thậm chí còn có ý nghĩa?

Ví dụ, có các biểu đồ trong ứng dụng của tôi. Tôi chưa thể tìm ra cách tự động hóa việc kiểm tra đồ thị. Phải mất một mắt người, AFAIK, để kiểm tra xem biểu đồ có đúng không.

(Tôi đang sử dụng Java Swing)

Các thiết kế như MVP và MVC thường cố gắng trừu tượng hóa càng nhiều logic ra khỏi GUI thực tế càng tốt. Một bài viết rất phổ biến về điều này là "Hộp thoại khiêm tốn" của Michael Feathers. Cá nhân tôi đã có những trải nghiệm lẫn lộn với việc cố gắng chuyển logic ra khỏi UI - đôi khi nó hoạt động rất tốt và đôi khi nó lại gặp nhiều rắc rối hơn giá trị của nó. Đó là một phần bên ngoài lĩnh vực chuyên môn của tôi mặc dù.

Tất nhiên, câu trả lời là sử dụng MVC và di chuyển càng nhiều logic ra khỏi GUI càng tốt.

Điều đó đã được nói, tôi đã nghe từ một đồng nghiệp cách đây rất lâu rằng khi SGI chuyển OpenGL sang phần cứng mới, họ đã có một loạt các bài kiểm tra đơn vị sẽ vẽ một tập hợp nguyên thủy lên màn hình sau đó tính tổng MD5 của bộ đệm khung. Giá trị này sau đó có thể được so sánh với các giá trị băm tốt đã biết để nhanh chóng xác định xem API có chính xác trên mỗi pixel hay không.

Bạn có thể thử UISpec4J là thư viện thử nghiệm đơn vị và / hoặc chức năng nguồn mở cho các ứng dụng Java dựa trên Swing ...

Có Selenium RC , sẽ tự động kiểm tra giao diện người dùng dựa trên web. Nó sẽ ghi lại hành động và phát lại chúng. Bạn vẫn sẽ cần thực hiện các tương tác với giao diện người dùng của mình, vì vậy điều này sẽ không giúp bảo hiểm, nhưng nó có thể được sử dụng cho các bản dựng tự động.

Bạn có thể thử sử dụng dưa chuột và Swinger để viết các bài kiểm tra chấp nhận chức năng bằng tiếng Anh đơn giản cho các ứng dụng GUI GUI. Swinger sử dụng thư viện Jemmy của Netbeans dưới mui xe để lái ứng dụng.

Dưa chuột cho phép bạn viết các bài kiểm tra như thế này:

 Scenario: Dialog manipulation
    Given the frame "SwingSet" is visible
    When I click the menu "File/About"
    Then I should see the dialog "About Swing!"
    When I click the button "OK"
    Then I should not see the dialog "About Swing!"

Hãy xem bản demo video Swinger này để thấy nó hoạt động.

Đây là một số lời khuyên:

Cố gắng loại bỏ hầu hết các mã bạn có thể ra khỏi GUI (có bộ điều khiển và đối tượng mô hình) theo cách này bạn sẽ có thể kiểm tra chúng mà không cần GUI.

Đối với đồ họa, bạn nên kiểm tra giá trị mà bạn cung cấp cho mã tạo ra đồ họa.

Kiểm tra là một hình thức nghệ thuật. Tôi đồng ý logic nên được loại bỏ GUI càng nhiều càng tốt. Sau đó chúng tôi có thể tập trung kiểm tra đơn vị của chúng tôi ở đó. Giống như bất cứ điều gì khác kiểm tra là về giảm rủi ro. Bạn không phải lúc nào cũng cần kiểm tra mọi thứ nhưng rất nhiều lần, điều tốt nhất là phá vỡ các thử nghiệm khác nhau ở các khu vực khác nhau.

Câu hỏi còn lại là bạn thực sự đang cố gắng thử nghiệm điều gì ở lớp UI. Kiểm tra giao diện người dùng là thử nghiệm đắt nhất vì thường mất nhiều thời gian hơn để tạo, duy trì và nó dễ vỡ nhất. Nếu bạn kiểm tra logic để biết tọa độ là chính xác trước khi thử vẽ đường thì bạn đang kiểm tra cụ thể là gì? Nếu bạn muốn kiểm tra một biểu đồ với một đường màu đỏ được vẽ. Bạn có thể cung cấp cho nó một tọa độ được xác định trước và kiểm tra xem một số pixel nhất định có màu đỏ hay không màu đỏ không? Như đã đề xuất so sánh bitmap ở trên, Selenium nhưng trọng tâm chính của tôi sẽ không phải là kiểm tra quá mức GUI mà là kiểm tra logic sẽ giúp tạo UI và sau đó tập trung vào phần nào của UI bị hỏng hoặc nghi ngờ và tập trung vào một số thử nghiệm ở đó

Bạn có thể sử dụng JFCUnit để kiểm tra GUI của mình, nhưng đồ họa có thể khó khăn hơn. Tôi đã đôi lần chụp ảnh GUI của mình và tự động so sánh nó với phiên bản trước. Mặc dù điều này không cung cấp thử nghiệm thực tế, nhưng nó sẽ cảnh báo bạn nếu bản dựng tự động không tạo ra đầu ra dự kiến.

Điều tôi thu thập được từ câu hỏi của bạn là bạn đang tìm kiếm một cách tự động để kiểm tra chi tiết hành vi GUI của bạn, ví dụ bạn đưa ra là kiểm tra xem một đường cong có thực sự được vẽ chính xác hay không.

Các khung kiểm thử đơn vị cung cấp một cách để thực hiện kiểm thử tự động, nhưng tôi nghĩ loại kiểm thử bạn muốn thực hiện là các kiểm thử tích hợp phức tạp để xác minh hành vi chính xác của vô số các lớp, trong đó các lớp của thư viện / bộ công cụ GUI của bạn, mà bạn không nên thử.

Các tùy chọn của bạn phụ thuộc rất nhiều vào nền tảng / bộ công cụ / khung công tác nào bạn sử dụng: ví dụ: một ứng dụng sử dụng Qt vì khung GUI của nó có thể sử dụng Squish để tự động hóa các thử nghiệm của nó. Bạn xác minh kết quả kiểm tra của mình một lần và các kiểm tra được thực hiện tự động tiếp theo sẽ so sánh kết quả với kết quả được xác minh.

Cửa sổ Licker cho Swing & Ajax

Cách tiếp cận của tôi để kiểm tra GUI đang phát triển, cũng như sự đồng thuận trong ngành. Nhưng tôi nghĩ rằng một vài kỹ thuật chính đang bắt đầu xuất hiện.

Tôi sử dụng một hoặc nhiều trong số các kỹ thuật này, tùy thuộc vào tình huống (ví dụ: loại GUI này là gì, nó cần được xây dựng nhanh như thế nào, người dùng cuối sẽ là ai, v.v.).

1. Kiểm tra bằng tay. Bạn luôn có GUI chạy trong khi làm việc với mã và đảm bảo nó đồng bộ với mã. Bạn kiểm tra thủ công và kiểm tra lại phần mà bạn làm việc khi bạn làm việc với nó, chuyển đổi giữa mã và ứng dụng đang chạy. Mỗi khi bạn hoàn thành một số công việc quan trọng, bạn sẽ kiểm tra toàn bộ màn hình hoặc khu vực của ứng dụng để đảm bảo không có hồi quy.

2. Kiểm tra đơn vị. Bạn viết kiểm tra cho các chức năng hoặc các đơn vị nhỏ của hành vi GUI. Ví dụ: biểu đồ của bạn có thể cần tính toán các sắc thái khác nhau của màu dựa trên màu 'cơ sở'. Bạn có thể trích xuất phép tính này cho một hàm và viết một bài kiểm tra đơn vị cho nó. Bạn có thể tìm kiếm logic như thế này trong GUI (đặc biệt là logic có thể sử dụng lại) và trích xuất nó thành các chức năng kín đáo, có thể dễ dàng kiểm tra đơn vị hơn. Ngay cả hành vi phức tạp cũng có thể được trích xuất và kiểm tra theo cách này - ví dụ: một chuỗi các bước trong trình hướng dẫn có thể được trích xuất thành hàm và kiểm tra đơn vị có thể xác minh rằng, được đưa vào một đầu vào, bước chính xác được trả về.

3. Thám hiểm thành phần. Bạn tạo một màn hình 'thám hiểm' với vai trò duy nhất là hiển thị từng thành phần có thể sử dụng lại tạo nên GUI của bạn. Màn hình này cung cấp cho bạn một cách nhanh chóng và dễ dàng để xác minh trực quan rằng mọi thành phần đều có giao diện chính xác. Trình thám hiểm thành phần hiệu quả hơn so với việc truy cập thủ công toàn bộ ứng dụng của bạn, vì A) bạn chỉ phải xác minh từng thành phần một lần và B) bạn không phải điều hướng sâu vào ứng dụng để xem thành phần, bạn chỉ có thể xem và xác minh nó ngay lập tức.

4. Kiểm tra tự động hóa. Bạn viết một bài kiểm tra tương tác với màn hình hoặc thành phần, mô phỏng các lần nhấp chuột, nhập dữ liệu, v.v., khẳng định rằng các chức năng của ứng dụng được cung cấp chính xác các thao tác này. Điều này có thể hữu ích như một thử nghiệm sao lưu bổ sung, để nắm bắt các lỗi tiềm ẩn mà các thử nghiệm khác của bạn có thể bỏ lỡ. Tôi có xu hướng bảo lưu thử nghiệm tự động hóa cho các phần của GUI dễ bị hỏng nhất và / hoặc rất quan trọng. Những phần mà tôi muốn biết càng sớm càng tốt nếu có thứ gì đó bị hỏng. Điều này có thể bao gồm các thành phần tương tác rất phức tạp dễ bị phá vỡ hoặc màn hình chính quan trọng.

5. Kiểm tra khác biệt / chụp nhanh. Bạn viết một bài kiểm tra chỉ đơn giản là chụp đầu ra dưới dạng ảnh chụp màn hình hoặc dưới dạng mã HTML và so sánh nó với đầu ra trước đó. Bằng cách đó, bạn đã cảnh báo bạn bất cứ khi nào đầu ra thay đổi. Các thử nghiệm khác nhau có thể hữu ích nếu khía cạnh trực quan của GUI của bạn phức tạp và / hoặc có thể thay đổi, trong trường hợp đó, bạn muốn phản hồi nhanh và trực quan về tác động của một thay đổi nhất định đối với GUI nói chung.

Thay vì mạnh tay sử dụng mọi loại thử nghiệm có thể, tôi thích chọn và chọn kỹ thuật thử nghiệm dựa trên loại thử nghiệm mà tôi đang làm. Vì vậy, trong một trường hợp, tôi sẽ trích xuất một hàm đơn giản và kiểm tra đơn vị nó, nhưng trong trường hợp khác tôi sẽ thêm một thành phần vào trình thám hiểm thành phần, v.v. Nó phụ thuộc vào tình huống.

Tôi chưa tìm thấy phạm vi bảo hiểm mã là một số liệu rất hữu ích, nhưng những người khác có thể đã tìm thấy việc sử dụng nó.

Tôi nghĩ rằng biện pháp đầu tiên là số lượng và mức độ nghiêm trọng của lỗi. Ưu tiên hàng đầu của bạn có lẽ là có một ứng dụng hoạt động chính xác. Nếu ứng dụng hoạt động chính xác, sẽ có ít hoặc không có lỗi. Nếu có nhiều hoặc nghiêm trọng, thì có lẽ, bạn không kiểm tra hoặc các xét nghiệm của bạn không hiệu quả.

Ngoài việc giảm lỗi, còn có các biện pháp khác như hiệu suất, khả năng sử dụng, khả năng truy cập, khả năng bảo trì, khả năng mở rộng, v.v ... Những cách này sẽ khác nhau, tùy thuộc vào loại ứng dụng bạn đang xây dựng, doanh nghiệp, người dùng cuối, v.v.

Đây là tất cả dựa trên kinh nghiệm và nghiên cứu cá nhân của tôi cũng như một bài viết tuyệt vời về Kiểm tra giao diện người dùng của Ham Vocke .

Từ những gì tôi biết, điều này khá phức tạp và thực sự phụ thuộc vào ngôn ngữ - nhiều ngôn ngữ có cách kiểm tra GUI riêng, nhưng nếu bạn thực sự cần kiểm tra GUI (trái ngược với tương tác mô hình / gui), bạn thường phải mô phỏng một nút bấm người dùng thực tế. Ví dụ, khung SWT được sử dụng trong Eclipse cung cấp SWTBot , JFCUnit đã được đề cập, Mozilla có cách mô phỏng riêng của họ trong XUL (và từ những gì tôi đã đọc trên blog của họ, các thử nghiệm này dường như khá dễ vỡ).

Đôi khi bạn phải chụp ảnh màn hình và kiểm tra kết xuất hoàn hảo pixel (tôi tin rằng Mozilla thực hiện điều này để kiểm tra các trang được hiển thị chính xác) - điều này đòi hỏi phải thiết lập dài hơn, nhưng có thể là những gì bạn cần cho biểu đồ. Bằng cách đó, khi bạn cập nhật mã của mình và ngắt kiểm tra, bạn phải kiểm tra hình ảnh theo cách thủ công nếu lỗi là có thật hoặc bạn đã cải thiện mã kết xuất biểu đồ để tạo biểu đồ đẹp hơn và cần cập nhật ảnh chụp màn hình.

Nếu bạn đang sử dụng Swing, FEST-Swing rất hữu ích để điều khiển GUI và kiểm tra các xác nhận của bạn. Việc kiểm tra những thứ như "nếu tôi nhấp vào nút A, hộp thoại B sẽ được hiển thị" hoặc "nếu tôi chọn tùy chọn 2 từ trình đơn thả xuống, tất cả các hộp kiểm sẽ được bỏ chọn" .

Kịch bản đồ thị mà bạn đề cập không dễ kiểm tra. Thật dễ dàng để có được phạm vi bảo hiểm mã cho các thành phần GUI chỉ bằng cách tạo và hiển thị chúng (và có thể điều khiển chúng bằng FEST). Tuy nhiên, thực hiện các xác nhận có ý nghĩa là phần khó (và bảo hiểm mã mà không có xác nhận có ý nghĩa là một bài tập trong tự lừa dối). Làm thế nào để bạn kiểm tra rằng đồ thị không được vẽ lộn ngược hoặc quá nhỏ?

Tôi nghĩ rằng bạn chỉ cần chấp nhận rằng một số khía cạnh của GUI không thể được kiểm tra hiệu quả bằng các thử nghiệm đơn vị tự động và bạn sẽ phải kiểm tra chúng theo những cách khác.

Đây không phải là công việc của bạn để kiểm tra thư viện GUI. Vì vậy, bạn có thể né tránh trách nhiệm kiểm tra những gì thực sự được vẽ trên màn hình và kiểm tra các thuộc tính của widget thay vào đó, tin tưởng vào thư viện rằng chúng thể hiện chính xác những gì được vẽ.