views:

593

answers:

3

I am having many java beans in my project. I need to generate a JUnit Test class for them. The test methods generated using eclipse IDE 3.2 & junit 4.4 for the beans are like...

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");
    }

some of my beans r having more then 100 fields...

is there a way by which I can get a single test method for both the getters & setters like testEmployeeid(), testName() so that in these methods I can test both my setters & getters rather then using 2 diff. test methods for them...

What configurations do I need to make for the same in eclipse?

+7  A: 

The philosophy of Test Driven Development says "test everything which can possibly break". That is, focus your efforts on the useful tests, instead of writing tests for just the sake of it.

Getters and setters are almost always trivial code, which is not worth testing by themselves.

I know this is not a straight answer to your plea, but I thought it may still help to point this out ;-) So why do you actually need to write tests for all those getters and setters in the first place?

Péter Török
+1 I agree that accessor methods don't need testing. I'm missing a feature that would allow them to be declared by an annotation.
stacker
I disagree strongly. You test the setters and getters for *regression* purposes, such that when your setters/getters change to be more complex, the tests confirm that they still function as before.
Brian Agnew
Yeah, would be nice. Java is too verbose on occasions. C# got this one better.
Péter Török
Checkout <a href="http://projectlombok.org/" Project Lombok</a> for annotation based approach, or switch to something like Groovy.Groovy is sort of Java++, but also adds dynamic programming. You don't have to use it, but it's there.Can rename a .java to .groovy, and groovyc is happy. Then, can use features want from there.
Mikezx6r
@Brian: IMO your case is fully covered by the above maxim. If there is a big enough chance that my getter/setter implementation may get more complex in the foreseeable future, then I write my little tests of course. However, I would say that your "when" still looks like a rather a big "if" to me ;-)
Péter Török
I agree with @Brian. Yes it is true that most Getters and Setters are trivial, which makes testing them trivial. However aside from the regression testing point that @Brian made, testing them can also ensure that things are getting set properly by constructors to. Or if someone extends your class and *doesn't* set something properly. I've argued this with other poeple numerous times, but they are always extremely easy to implement, easier than arguing about it sometimes, especially on the off chance that it does save you time later on.
Casey
Péter Török
@Péter well in my experience (short as it may be), when working with Legacy code, it's a whole other ball game. I've been workign with an ASP.NET/C# site for the past 6 months now, trying to fit unit testing into it without causing too much damage. The whole thing is horribly written and I have focused my unit testing on parts of it that really need to stay working and refactoring what and when I can around it.
Casey
@Casey sounds familiar - just the languages and acronyms vary :-) :-(
Péter Török
@Péter yeah. it's almost always the same concepts, just different syntax.
Casey
+2  A: 

You could perhaps use Apache Commons 'beanutils' to help automate this:

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

For instance there is a method describe(Object bean) which will return a map of all the readable attributes (ie, getters).

Then iterate that map and call:

setSimpleProperty(Object bean, String name, Object value)

and

public static Object getSimpleProperty(Object bean, String name)

And although I agree with the other poster than getters/setters are pretty trivial - I think it is still worth testing them - to eliminate typos, test property change listeners etc.

For example, this will dynamically extract the getters of 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;
    }}

You will need to download both BeanUtils and CommonsLogging and both libraries' JARs to your project to run this code.

monojohnny
+4  A: 

If you have 100 fields in a class (with corresponding setters/getters) I suspect your object model is not decomposed correctly. 100+ fields sounds like an extraordinary number of fields for an object, and I would guess that it has several responsibilities that can be split across a number of more specialised objects.

Brian Agnew