Kiểm tra JUnit cho POJOs

Question

Tôi làm việc trên một dự án mà chúng tôi phải tạo các xét nghiệm đơn vị cho tất cả các hạt đơn giản của chúng tôi (POJO). Có bất kỳ điểm nào để tạo ra một bài kiểm tra đơn vị cho POJO nếu tất cả chúng bao gồm getters và setters không? Có phải giả định an toàn để giả định POJO sẽ hoạt động khoảng 100% thời gian không?

---

Duplicate của - Should @Entity Pojos be tested?

Xem thêm

Is it bad practice to run tests on a DB instead of on fake repositories?

Is there a Java unit-test framework that auto-tests getters and setters?

Answer 1

Quy tắc trong TDD là "Test everything that could possibly break" Có thể ngắt kết nối không? Nói chung là không, vì vậy tôi không bận tâm để kiểm tra nó. Bên cạnh đó, mã I do kiểm tra chắc chắn sẽ gọi cho getter để nó sẽ được kiểm tra.

Quy tắc cá nhân của tôi là tôi sẽ viết một bài kiểm tra cho bất kỳ chức năng nào đưa ra quyết định hoặc làm nhiều hơn một phép tính tầm thường. Tôi sẽ không viết một bài kiểm tra cho i+1, nhưng tôi có thể sẽ cho if (i<0)... và chắc chắn sẽ cho (-b + Math.sqrt(b*b - 4*a*c))/(2*a).

BTW, sự nhấn mạnh vào POJO có lý do khác đằng sau nó. Chúng tôi muốn số lượng lớn mã của chúng tôi được viết vào POJOs rằng không phụ thuộc vào môi trường mà chúng chạy trong. Ví dụ, thật khó để kiểm tra servlet, bởi vì chúng phụ thuộc vào việc thực thi bên trong một thùng chứa. Vì vậy, chúng tôi muốn các servlet gọi POJO không phụ thuộc vào môi trường của chúng và do đó dễ kiểm tra.

Answer 2

POJO cũng có thể chứa các chức năng khác, chẳng hạn như equals(), hashCode(), compareTo() và các hàm khác. Có thể hữu ích khi biết rằng các chức năng đó hoạt động chính xác.

Answer 3

Tôi không nghĩ rằng có một điểm để kiểm tra getters và setters thuộc tính đơn giản. Điểm kiểm thử đơn vị không phải là để xác minh rằng trình biên dịch của bạn hoạt động.

Tuy nhiên, ngay khi bạn thêm một điều kiện, kiểm tra null hoặc hành vi không tầm thường khác vào getters và setters của bạn (hoặc các phương pháp khác) tôi nghĩ rằng nó thích hợp để thêm các bài kiểm tra đơn vị.

Answer 4

Tôi nghĩ rằng nếu các getters và setters đã được tạo ra bằng cách sử dụng một IDE thì nó sẽ được sử dụng tốt. Chúng tôi có những thứ khác để đưa mã của chúng tôi vào. Rõ ràng, bạn sẽ kiểm tra của POJO cho serialization/de-serialization.

Answer 5

Câu trả lời của tôi là các thiết bị định vị và định vị tầm thường không xứng đáng với các thử nghiệm của riêng chúng. Nếu tôi thêm bất kỳ mã nào khác ngoài các lần đọc hoặc viết đơn giản, thì tôi sẽ thêm các thử nghiệm.

Tất nhiên, đây là tất cả các bản mẫu, vì vậy bạn có thể dễ dàng viết một kịch bản tạo ra các bài kiểm tra đơn vị cho getters và setters của bạn, nếu bạn nghĩ rằng có bất kỳ giá trị ở đó. Một số IDE có thể cho phép bạn định nghĩa một mẫu tạo ra các test test với các phương thức test được điền vào cho mã boilerplate này (tôi nghĩ về IntelliJ ở đây, nhưng Eclipse có thể xử lý nó). IDE).

Answer 6

Theo kinh nghiệm của tôi, việc tạo các bài kiểm tra đơn vị cho POJO chỉ với getters và setters, chỉ là quá mức cần thiết. Có một số trường hợp ngoại lệ, tất nhiên, nếu có thêm logic trong getter/setter như kiểm tra null và làm một cái gì đó đặc biệt, hơn tôi sẽ tạo ra một bài kiểm tra đơn vị cho điều đó.

Ngoài ra, nếu có lỗi trong POJO, tôi sẽ tạo một bài kiểm tra đơn vị cho nó để chúng tôi có thể ngăn điều đó xảy ra lần nữa.

Answer 7

Đây có thể là giá trị một thử nghiệm đơn giản để chắc chắn rằng bạn đã không được viết

public void setX(int x) { 
    x = x; 
} 

Mặc dù bạn nên mã hóa để tránh điều đó (bằng cách đặt một modifier final trên tham số phương pháp, hoặc tương tự). Nó cũng phụ thuộc vào cách bạn đang tạo ra accessors của bạn, và nếu họ có thể bị sao chép/dán lỗi vv (điều này sẽ xảy ra ngay cả trong các môi trường cố gắng để thực thi việc sử dụng IDE - nó sẽ chỉ).

Mối quan tâm chính của tôi với các lớp học chứa nhiều người định cư/getters, tuy nhiên, là lớp học đang làm gì? Đối tượng nên làm công cụ cho bạn, thay vì chỉ giữ và trả lại dữ liệu. Nếu đây là các đối tượng thực thể dữ liệu thì mẫu setter/getter có thể đúng.Tuy nhiên, mô hình tốt hơn là đặt dữ liệu trong đối tượng và yêu cầu đối tượng làm việc với nó (tính số dư ngân hàng của bạn, khởi chạy tên lửa, v.v.) thay vì trả lại dữ liệu và để bạn tự làm điều đó!

Answer 8

Mã kiểm tra đơn vị bạn muốn biết hoạt động (đối với các trường hợp được kiểm tra tất nhiên). Không đơn vị kiểm tra mã bạn chỉ muốn được loại công trình chắc chắn.

Tôi không thể nghĩ nhiều đến mức tôi chỉ muốn chắc chắn về điều đó.

Answer 9

Tôi đã từng trải qua hai tiếng đồng hồ vì một cái gì đó như thế này:

int getX() 
{ 
    return (x); 
} 

int getY() 
{ 
    return (x); // oops 
} 

Kể từ khi phải mất hầu như không có thời gian để viết các bài kiểm tra cho thu khí đơn giản, tôi làm ngay bây giờ theo thói quen.

Answer 10

Tôi đang thử nghiệm với cobatura cho phạm vi mã và chỉ gặp vấn đề tương tự.

Thật tuyệt khi có chú thích để thêm vào lớp cho biết không bao gồm lớp này trong phạm vi mã. Tuy nhiên, có thể đặt pojo của bạn trong một gói riêng biệt và sau đó loại trừ gói đó khỏi phân tích.

Xem tài liệu tùy thuộc vào công cụ của bạn, nó hoạt động với Ant, Maven hoặc dòng lệnh.

Answer 11

Tôi sử dụng IntelliJ làm IDE và viết khá nhiều POJO tầm thường đối với tôi - chắc chắn là hàm tạo và getters/settors. Tôi không thấy bất kỳ điểm nào trong bài kiểm tra đơn vị này vì bất kỳ lỗi nào sẽ có nhiều khả năng nằm trong mã thử nghiệm mà tôi viết.

Answer 12

Tôi vừa mới bắt đầu một dự án để thực hiện việc này. trong giai đoạn tiền alpha của nó ngay bây giờ. Nó là một plugin Eclipse.

Mặc dù tôi đồng ý rằng một trình gỡ/cài đặt POJO không nhất thiết cần thử nghiệm, tôi tin rằng việc thử nghiệm đơn giản là tốt nhất vì mọi thứ thay đổi theo thời gian, nó sẽ giúp bạn dễ dàng thêm kiểm tra cho POJO. Bài kiểm tra Unit được thiết lập, các phương thức có để kiểm tra setter/getter, tất cả những gì bạn phải làm là xử lý sự phức tạp mới.

Điều này cũng giúp với các báo cáo về mức độ phù hợp mã, giúp báo cáo người quản lý hài lòng. (Công ty của tôi sử dụng Emma).

https://sourceforge.net/projects/unittestgplugin/

Answer 13

Unit tests không chỉ xác nhận mã mà hoạt động đúng, nhưng họ ghi lại hành vi mong đợi.Tôi không biết bao nhiêu lần tôi đã thấy mọi thứ bị phá vỡ bởi vì một số thời gian xuống đường, ai đó thay đổi hành vi của một getter hoặc setter trong POJO và sau đó nó bất ngờ phá vỡ một cái gì đó khác (ví dụ, ai đó thêm logic cho setter nếu ai đó thiết lập một giá trị null trên một chuỗi, setter thay đổi nó thành một chuỗi rỗng để NPE không xảy ra).

Tôi không xem xét các bài kiểm tra đơn vị về lưu trữ dữ liệu POJO như một sự lãng phí thời gian, tôi coi chúng như một mạng lưới an toàn để bảo trì trong tương lai. Điều đó đang được nói, nếu bạn đang tự viết các bài kiểm tra để xác nhận các đối tượng này, bạn đang làm nó một cách khó khăn. Hãy xem một cái gì đó như http://gtcgroup.com/testutil.html

Answer 14

Có một tiện ích nguồn mở http://meanbean.sourceforge.net/ cho phép bạn kiểm tra POJO. Ngoài ra còn có một trang mô tả các giá trị/câu hỏi mà một người có thể có về những gì tiện ích này cung cấp và tại sao nó nên được sử dụng.

Tôi chưa bao giờ cảm thấy mệt mỏi (nhưng), nhưng nó đã được giới thiệu cho tôi.

Answer 15

1. SỬ DỤNG THƯ VIỆN: sử dụng thư viện hiện có giúp kiểm tra POJO. Một trong những thư viện mà tôi đã đi qua là có nghĩa là.

   Ref: http://meanbean.sourceforge.net/

   Maven: http://mvnrepository.com/artifact/org.meanbean/meanbean (phiên bản hiện tại: 2.0.3)

2. IGNORE POJO: Sonar có thể được cấu hình để loại trừ các POJO hoặc gói cụ thể được loại trừ khỏi unit- kiểm tra báo cáo bảo hiểm. Vài ví dụ dưới đây:

   <properties> 
       <sonar.coverage.exclusions> 
        **/domain/**/*, 
        **/pojos/* 
       </sonar.coverage.exclusions> 
   </properties> 
   

Answer 16

Vấn đề này có thể được giải quyết bằng cách sử dụng thư viện Lombok mà loại bỏ tất cả các mã boilerplate này cũng như equals và hashCode.

Vì vậy, bạn không cần phải kiểm tra chúng, trừ khi bạn có một yêu cầu cụ thể đối với equals và hashCode

https://projectlombok.org/