Có khung kiểm thử đơn vị Java tự động kiểm tra getters và setters không?

Question

Có một cuộc tranh luận nổi tiếng trong Java (và các cộng đồng khác, tôi chắc chắn) có nên thử nghiệm các phương thức getter/setter tầm thường hay không. Thông thường, điều này là đối với phạm vi mã. Hãy đồng ý rằng đây là một cuộc tranh luận mở, và không cố gắng trả lời nó ở đây.

Đã có một số bài đăng trên blog về cách sử dụng phản chiếu Java để tự động kiểm tra các phương pháp như vậy.

Có khung nào (ví dụ: jUnit) cung cấp tính năng như vậy không? ví dụ. Một chú thích cho biết "thử nghiệm này T sẽ tự động kiểm tra tất cả các getters/setters trên lớp C, bởi vì tôi khẳng định rằng chúng là tiêu chuẩn".

Dường như với tôi rằng nó sẽ thêm giá trị và nếu được cấu hình, 'cuộc tranh luận' sẽ được để lại dưới dạng tùy chọn cho người dùng.

Answer 1

Unitils thực hiện điều này bằng phương pháp tĩnh assertRefEquals.

Answer 2

Tôi không biết bất kỳ thư viện hoặc lớp học sẵn có nào thực hiện việc này. Điều này chủ yếu có thể là do tôi không quan tâm vì tôi đang ở bên cạnh phản đối mạnh mẽ các xét nghiệm như vậy. Vì vậy, mặc dù bạn đã yêu cầu có phải là một chút biện minh cho chế độ xem này:

Tôi nghi ngờ rằng việc thu thập thông tin và định vị có lợi cho chất lượng mã của bạn hoặc mức độ phù hợp của bạn: ví dụ: 100% được bảo hiểm) hoặc không được sử dụng ở tất cả (và có thể được loại bỏ). Cuối cùng, bạn sẽ để lại getters và setters bởi vì chúng được sử dụng từ test nhưng không có nơi nào khác trong ứng dụng.

Sẽ dễ dàng để viết thử nghiệm như vậy, ví dụ: với Apache Commons BeanUtils, nhưng tôi nghi ngờ bạn thực sự cần nó nếu bạn có các bài kiểm tra tốt khác.

Answer 3

Tôi sẽ ưu tiên thiết kế OO trên phạm vi mã và xem liệu tôi có thể di chuyển các trường đó đến lớp cần chúng hay không. Vì vậy, tôi sẽ cố gắng để xem nếu những getters và setters có thể được gỡ bỏ, như đề xuất trước. getters và setters là breaking encapsulation.

Answer 4

Trong hầu hết các trường hợp, setter và getter làm nhiều hơn khi chỉ thiết lập và nhận được một trường nội bộ. Một đối tượng phải kiểm tra các quy tắc nội bộ mà nó chỉ giữ các giá trị hợp lệ. Ví dụ:

• là giá trị rỗng có thể?
• là các chuỗi rỗng có thể không?
• hoặc giá trị âm?
• hoặc giá trị bằng 0?
• hoặc giá trị từ danh sách hợp lệ?
• hoặc có giá trị tối đa không?
• hoặc có độ chính xác tối đa trên các giá trị BigDecimal không?

Kiểm tra đơn vị nên kiểm tra xem hành vi có chính xác không nếu có giá trị không hợp lệ. Điều này không thể được tự động.

Nếu bạn không có logic trên setter và getter sau đó nó phải được sử dụng bất cứ nơi nào trong ứng dụng của bạn. Viết một bài kiểm tra nơi đối tượng của bạn là một tham số cho một bài kiểm tra phức tạp hơn. Bạn có thể kiểm tra nó sau đó với các giá trị khác nhau từ danh sách.

Kiểm tra logic nghiệp vụ của bạn chứ không phải trình khởi động và thiết lập. Kết quả cũng phải là một vùng phủ sóng của getter và setter. Các phương pháp cũng nên có bất kỳ kết quả nào trong logic nghiệp vụ của bạn nếu bạn chỉ có một thư viện công cộng. Nếu getter và setter không có mã vùng phủ sóng thì hãy xóa nó đi.

Answer 5

Trả lời nhận xét trước đó tại @me đây vì danh tiếng của tôi:

Vlookward, không viết getters/setters làm cho không có ý nghĩa gì cả. Các tùy chọn duy nhất để thiết lập các trường riêng là có các bộ định vị rõ ràng, để đặt chúng trong hàm tạo của bạn, hoặc để thiết lập gián tiếp thông qua các phương thức khác (trì hoãn hàm setter đến vị trí khác). Tại sao không sử dụng setters?

Vâng, đôi khi, không cần đến trường là riêng tư (Xin lỗi nếu tiếng Anh của tôi không tốt). Thông thường, chúng tôi viết phần mềm của chúng tôi vì nó là một thư viện và chúng tôi đóng gói các lĩnh vực của chúng tôi (các lĩnh vực logic kinh doanh của chúng tôi) với các getters/setters không cần thiết.

Lần khác, các phương pháp đó thực sự cần thiết. Sau đó, có hai khả năng:
1. Có logic nghiệp vụ bên trong chúng. Sau đó, họ sẽ được thử nghiệm, nhưng họ không phải là getters/setters thực sự. Tôi luôn viết logic đó trong các lớp khác. Và các bài kiểm tra kiểm tra các lớp khác, không phải là POJO.
2. Không có. Sau đó, không viết chúng bằng tay, nếu bạn có thể. Ví dụ: triển khai cho giao diện tiếp theo có thể được tạo tự động hoàn toàn (và cũng trong thời gian chạy!):

interface NamedAndObservable { 
    String getName(); 
    void setName(String name); 
    void addPropertyChangeListener(PropertyChangeListener listener); 
    void addPropertyChangeListener(String propertyName, 
           PropertyChangeListener listener); 
} 

Vì vậy, chỉ kiểm tra những gì được viết bằng tay. Không có vấn đề nếu nó là một getter/setter.

Answer 6

Tôi đã làm điều gì đó tương tự. Một lớp java đơn giản lấy một đối tượng và kiểm tra tất cả các phương thức getters và setter. http://sourceforge.net/projects/getterandsetter/

Tôi nghĩ bạn nên tránh các phương pháp getter và setter càng nhiều càng tốt, nhưng miễn là chúng xung quanh và phải mất hai dòng để kiểm tra chúng, đó là một điều tốt để làm điều đó.

Answer 7

I am trying out openpojo

Tôi đã đá và lốp xe dường như thực hiện công việc.

1. Nó cho phép bạn kiểm tra tất cả các pojo trong dự án của bạn.
2. Dường như để kiểm tra các thông lệ tốt nhất trên POJO của

Kiểm tra hướng dẫn này cho một sự khởi đầu nhanh chóng Tutorial

Answer 8

tôi tạo ra các dự án OpenPojo để giải quyết chính xác vấn đề này.

Dự án cho phép bạn xác nhận:

• Enforce POJO tiêu chuẩn mã hóa (ví dụ: Tất cả các lĩnh vực tư nhân, hoặc không có biến bản xứ, ... vv)
• Enforce hành vi POJO (tức là setter không JUST thiết, không chuyển đổi, v.v.)
• Xác thực nhận dạng Pojo (ví dụ:Sử dụng chú thích dựa bình đẳng & hệ hashcode)

See Tutorial

Answer 9

I guess this library is the answer to your question

nó kiểm tra tất cả các giá trị ban đầu của đậu, các setters, các getters, hashCode(), equals() and toString(). Tất cả những gì bạn phải làm là xác định một bản đồ mặc định và thuộc tính/giá trị không mặc định.

Nó cũng có thể kiểm tra các đối tượng là đậu với thêm constructor mặc định không.

Answer 10

Tôi không viết các trường hợp kiểm tra đối với từng tài sản, nhưng thay vào đó kiểm tra tất cả các setters/getters trong một trường hợp thử nghiệm đơn sử dụng phản chiếu/Introspector để xác định loại (s). Đây là một tài nguyên tuyệt vời cho thấy điều này:

http://www.nearinfinity.com/blogs/scott_leberknight/do_you_unit_test_getters.html