2010-02-07 43 views
6

Tôi có nhiều hạt java trong dự án của mình. Tôi cần tạo một lớp JUnit Test cho họ. Các phương pháp thử nghiệm được tạo ra sử dụng Eclipse 3.2 & junit 4.4 trông như sau:phương pháp kiểm tra junit cho getters & setters

public void testGetName() { 
     // fail("Not yet implemented"); 
    } 

    @Test 
    public void testSetName() { 
     // fail("Not yet implemented"); 
    } 

    @Test 
    public void testGetEmployeeid() { 
     // fail("Not yet implemented"); 
    } 

    @Test 
    public void testSetEmployeeid() { 
     // fail("Not yet implemented"); 
    } 

một số đậu của tôi đã hơn 100 lĩnh vực ...

Có cách nào để tôi có thể nhận được một thử nghiệm đơn phương pháp cho cả hai getters & setters như testEmployeeid(), testName() để trong các phương pháp này tôi có thể kiểm tra cả hai setters của tôi & getters thay vì sử dụng 2 diff. phương pháp thử nghiệm cho họ ...

Tôi nên định cấu hình nhật thực để thực hiện việc này như thế nào?

+0

trình cắm thêm nhật thực nào bạn đang sử dụng để tạo phương pháp thử nghiệm? – Yoni

+0

FWIW, câu hỏi sau đây cố gắng dành riêng cuộc tranh luận và hỏi xem có cách nào để tự động thực hiện theo sở thích của bạn hay không - http://stackoverflow.com/questions/108692 –

+5

Vấn đề ** thực ** ở đây hoàn toàn không liên quan để thử nghiệm đơn vị hoàn toàn: "* một số đậu của tôi r có nhiều hơn thì 100 trường *" ... cho bất kỳ người mới Java nào đọc câu hỏi này, hãy hiểu đây là chương trình * khủng khiếp *. Bất kỳ lớp nào có hơn 100 trường đều có trách nhiệm quá nhiều. Xem [this] (http://stackoverflow.com/questions/4683841/what-is-object-decomposition) nếu bạn không hiểu tại sao. – IAmYourFaja

Trả lời

25

Triết lý của Kiểm tra phát triển theo hướng nói "kiểm tra mọi thứ có thể có thể bị hỏng". Đó là, tập trung nỗ lực của bạn vào các bài kiểm tra hữu ích, thay vì viết các bài kiểm tra chỉ vì lợi ích của nó.

Getters and setters hầu như luôn là mã nhỏ, không đáng để thử nghiệm.

Tôi biết đây không phải là câu trả lời thẳng cho lời cầu xin của bạn, nhưng tôi nghĩ rằng nó vẫn có thể giúp chỉ ra điều này ;-) Vậy tại sao bạn thực sự cần phải viết các bài kiểm tra cho tất cả những getters và setters đó ngay từ đầu?

+1

+1 Tôi đồng ý rằng các phương thức truy cập không cần thử nghiệm. Tôi thiếu một tính năng cho phép họ được tuyên bố bằng chú thích. – stacker

+13

Tôi không đồng ý mạnh mẽ. Bạn kiểm tra các setters và getters cho * regression * nhằm mục đích, như vậy khi setters/getters của bạn thay đổi phức tạp hơn, các test sẽ xác nhận rằng chúng vẫn hoạt động như trước. –

+2

Vâng, sẽ rất tuyệt. Java là quá chi tiết vào những dịp. C# có cái này tốt hơn. –

5

Bạn có lẽ có thể sử dụng Apache Commons 'beanutils' để giúp tự động này:

http://commons.apache.org/beanutils/apidocs/org/apache/commons/beanutils/PropertyUtils.html#getSimpleProperty%28java.lang.Object,java.lang.String%29

Ví dụ có một phương pháp describe(Object bean) mà sẽ trả về một bản đồ của tất cả các thuộc tính có thể đọc được (ví dụ, thu khí).

Sau đó lặp bản đồ đó và gọi:

setSimpleProperty(Object bean, String name, Object value) 

public static Object getSimpleProperty(Object bean, String name) 

Và mặc dù tôi đồng ý với các poster khác hơn getters/setters là khá tầm thường - Tôi nghĩ rằng đó là vẫn còn giá trị thử nghiệm chúng - để loại bỏ lỗi chính tả, hãy kiểm tra trình nghe thay đổi thuộc tính, v.v.

Ví dụ: thao tác này sẽ trích xuất động getters của bean:

import java.io.Serializable; 
import java.util.Set; 
import org.apache.commons.beanutils.PropertyUtils; 

public class MyTestBean implements Serializable { 
    private int a; 
    private int b; 
    private int c; 
    private String x; 
    private String y; 
    private String z; 

    public static void main(String[] args) throws Exception { 
    MyTestBean bean=new MyTestBean(); 
    Set prop=PropertyUtils.describe(bean).keySet(); 
    for (Object o : prop) { 
     System.out.println((String)o); 
    } 
    } 

    public int getA() { 
     return a; 
    } 
    public void setA(int a) { 
     this.a = a; 
    } 
    public int getB() { 
     return b; 
    } 
    public void setB(int b) { 
     this.b = b; 
    } 
    public int getC() { 
     return c; 
    } 
    public void setC(int c) { 
     this.c = c; 
    } 
    public String getX() { 
     return x; 
    } 
    public void setX(String x) { 
     this.x = x; 
    } 
    public String getY() { 
     return y; 
    } 
    public void setY(String y) { 
     this.y = y; 
    } 
    public String getZ() { 
     return z; 
    } 
    public void setZ(String z) { 
     this.z = z; 
    }} 

Bạn sẽ cần phải tải xuống cả BeanUtils và CommonsLogging và cả hai thư viện 'JAR để dự án của bạn để chạy mã này.

11

Nếu bạn có 100 trường trong một lớp (với các bộ định cư/getters tương ứng), tôi nghi ngờ mô hình đối tượng của bạn không bị phân tách chính xác. Hơn 100 trường có vẻ giống như một số trường đặc biệt cho một đối tượng, và tôi đoán rằng nó có một số trách nhiệm có thể được chia thành nhiều đối tượng chuyên biệt hơn.

+0

Trong trường hợp thường xảy ra, nó có thể không nhất thiết phải sai khi có nhiều trường. Hãy tưởng tượng rằng lớp này tồn tại để cung cấp một ánh xạ Jaxb cho một tệp XML rất lớn, chẳng hạn. – Steve

3

Tôi đoán thư viện này là câu trả lời cho câu hỏi của bạn: http://outsidemybox.github.com/testUtils/

nó kiểm tra tất cả các giá trị của đậu ban đầu, setters, thu khí, hashCode(), tương đương với() và 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 các hàm tạo không mặc định bổ sung.

+0

Chỉ để tham khảo trong tương lai. Vui lòng không Sao chép và dán câu trả lời và cũng từ tự quảng bá. Cảm ơn bạn. – Bobby

Các vấn đề liên quan