Looking for an intelligent tool to generate junit tests

[Ajay]

Hello.

(For the past 3 hours) I am searching for a tool to generate junit
tests for rather mundane classes such as this:
package .....;

/**
* @junit
*/
public class CurveKey {
private Long curveId;
private String marketDataSetId;

// constructors, getters, setters snipped

@Override public int hashCode() {
// snipped for readability
}

@Override public boolean equals(Object obj) {
// snipped for readability
}

}
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

What I would like the tool to do is to generate some form of automated
test for getters, setters, hashcode and equals.

Anyone knows of anything I could use?

During my search, I came across Parasoft JTest, which costs real
money, and XDoclet 2 junit plugin: which I could not get to work
(discussion at the xdoclet mailing list). Apart from these two, I came
across, about 6 projects, all of which are in a dormant state.

What do you do for your mundane classes?

Any help / information will be highly appreciated.

Thanks in advance

Ajay

 

[Mark Space]

What I would like the tool to do is to generate some form of automated
test for getters, setters, hashcode and equals.

Have you tried NetBeans? That will generate JUnit tests automatically
for you.

 

[Christian]

Hello.

(For the past 3 hours) I am searching for a tool to generate junit
tests for rather mundane classes such as this:

package .....;

/**
* @junit
*/
public class CurveKey {
private Long curveId;
private String marketDataSetId;

// constructors, getters, setters snipped

@Override public int hashCode() {
// snipped for readability
}

@Override public boolean equals(Object obj) {
// snipped for readability
}

}
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

What I would like the tool to do is to generate some form of automated
test for getters, setters, hashcode and equals.

Anyone knows of anything I could use?

During my search, I came across Parasoft JTest, which costs real
money, and XDoclet 2 junit plugin: which I could not get to work
(discussion at the xdoclet mailing list). Apart from these two, I came
across, about 6 projects, all of which are in a dormant state.

What do you do for your mundane classes?

Any help / information will be highly appreciated.

Thanks in advance

Ajay

I would not test getters and setters at all as they are trivial..

hashcode and equals are usually automatically generated so not really
testworthy ...

 

[Danno]

Hello.

(For the past 3 hours) I am searching for a tool to generate junit
tests for rather mundane classes such as this:



package .....;

/**
 * @junit
 */
public class CurveKey  {
  private Long curveId;
  private String marketDataSetId;

  // constructors, getters, setters snipped

  @Override public int hashCode() {
        // snipped for readability
  }

  @Override public boolean equals(Object obj) {
        // snipped for readability
  }

}

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

What I would like the tool to do is to generate some form of automated
test for getters, setters, hashcode and equals.

Anyone knows of anything I could use?

During my search, I came across Parasoft JTest, which costs real
money, and XDoclet 2 junit plugin: which I could not get to work
(discussion at the xdoclet mailing list). Apart from these two, I came
across, about 6 projects, all of which are in a dormant state.

What do you do for your mundane classes?

Any help / information will be highly appreciated.

Thanks in advance

Ajay

Oh I did that in groovy, but for test ng. I just made an instance of
the bean, inspected it, and went nuts!

 

[Ajay]

I would not test getters and setters at all as they are trivial..

Not always.  Yes, usually, but not always.  And why not test them?  What's the
harm?

hashcode [sic] and equals are usually automatically generated so not really
testworthy ...

Not in my experience.  First of all, no tool knows what the relevant value
fields are; only the designer does.  Secondly, you can rely on blind faith,
but equals() and hashCode() (not "hashcode", come on) are far too important
for me to blithely suggest that they aren't "really testworthy".  They
arguably are in the set of methods that are most important to test.

And again, what's the harm in testing them?  What possible benefit is there to
reduced testing?  You should be urging developers to test more thoroughly,
more often and in more detail, not encouraging dangerous and foolish practices.

I concur with Lew.

Usually methods like getters, setters, hashcode and equals start out
with being auto generated and probably not test worthy. But
eventually, over time, things happen that cause more functionality to
be expected of memr getters and setters. I am not endorsing that view,
but somethings things are unavoidable.

I would like to generate these tests so that when someone else
enhances a getter (for instance), my code / test make sure then don't
mess something in my code.

Ajay

 

[Ajay]

Have you tried NetBeans? That will generate JUnit tests automatically
for you.

Ok... so I installed netbeans to try this out. I wrote a quick class,
and generated a test.

<rant>
Mark: WTF? Any tool / ide can generate an empty shell - eclipse
generates a dumb junit shell too. This is almost as bad as writing the
whole test yourself! I think I made it clear that I need an active
working test, not a shell that has 'fail("The test case is a
prototype.")' at the end of every test.

Damn, I wasted all this time. And even more time bitching about
netbeans.
</rant>

Am I missing something? Perhaps a netbeans plugin or a setting or
something else? Come on... spill the beans on this one...

Ajay

 

[Christian]

I would not test getters and setters at all as they are trivial..

Not always. Yes, usually, but not always. And why not test them? What's the
harm?

hashcode [sic] and equals are usually automatically generated so not really
testworthy ...

Not in my experience. First of all, no tool knows what the relevant value
fields are; only the designer does. Secondly, you can rely on blind faith,
but equals() and hashCode() (not "hashcode", come on) are far too important
for me to blithely suggest that they aren't "really testworthy". They
arguably are in the set of methods that are most important to test.

And again, what's the harm in testing them? What possible benefit is there to
reduced testing? You should be urging developers to test more thoroughly,
more often and in more detail, not encouraging dangerous and foolish practices.

I concur with Lew.

Usually methods like getters, setters, hashcode and equals start out
with being auto generated and probably not test worthy. But
eventually, over time, things happen that cause more functionality to
be expected of memr getters and setters. I am not endorsing that view,
but somethings things are unavoidable.

I would like to generate these tests so that when someone else
enhances a getter (for instance), my code / test make sure then don't
mess something in my code.

Ajay

Though I do not see how automatically created tests could find such
mistakes as lew named them.

Human written tests may be worth to test hashCode and equals ..
Though I would not seen how a machine created test will find bugs in
machine created code.

 

[Christian]

[...]

I would not test getters and setters at all as they are trivial..

Setters that throw exceptions for out-of-range or otherwise
invalid arguments might merit testing. Also, state-dependent
setters (consider `set(Calendar.DAY_OF_MONTH, 32)' on a lenient
or a non-lenient Calendar) are hard to describe as "trivial."

hashcode and equals are usually automatically generated so not really
testworthy ...

Hmmm. I'm obviously not using the right tools, because I
haven't seen either of these methods generated for me. How does
automatic generation distinguish between instance variables that
do and do not contribute to the "equals" notion? Annotations?
(C.f. the `hash' instance variable of java.lang.String, where
String instances whose `hash' values differ may nonetheless
compare equal).

Automatically in the sense that you ask your IDE to create them (eclipse
in my case) and the IDE asks you then what attributes of you class
should be used for equals and hashCode.

 

[Mark Space]

See the problem? You don't have enough information to know
what "correct" is! Was setFringe supposed to accept a null
argument, or throw an exception, or automagically substitute
Fringe.NO_FRINGE? Were setFringe and getFringe supposed to
make defensive copies? Was setFringe supposed to send a

Actually, I think he has a bit of a point.

Sure, most of what you say cannot be tested automatically (easily), but
the test generators could help you out and make a few more test cases
than they do.

Writing some simple boilerplate like:

1. Set property to null.
2. Get property and make sure result is null
3. Set property to default argument constructor object
4. Get property and make sure same argument is returned.

That would at least provide a skeleton that would be a bit easier to
modify to test for specific cases like you mention. To test for a
defensive copy, I could just change line 4 and make sure the same object
was NOT returned. But making the object and making the if-then test is
just boilerplate that could be generated for me.

I haven't done any programming on the NB platform itself, I wonder how
hard it would be to (optionally?) add some boilerplate to the unit test
generators.

 

[Philipp]

Christian wrote:

hashcode [sic] and equals are usually automatically generated so not
really testworthy ...

Hmmm. Do you have the last Eclipse release (3.3.2)?
Try this: Write a class with a single byte member and generate
hashCode() and equals().

Now check them and be surprised

Phil

 

[Todd]

Ajay,

There used to be a website called JUnitFactory.com (I keep getting
Network time-out errors now, so maybe it is just down), that uses the
AgitarOne engine to create unit tests. That might be closer to what
you are hoping for.

Beyond that, I have written a test harness using reflection to perform
repetitive testing of accessors and mutators. It is not automatic,
but it does reduce a lot of the effort.

Todd

 

[Christian]

Christian wrote:

hashcode [sic] and equals are usually automatically generated so not
really testworthy ...

Hmmm. Do you have the last Eclipse release (3.3.2)?
Try this: Write a class with a single byte member and generate
hashCode() and equals().

Now check them and be surprised

Phil

public class TestClass {

private byte a;

@Override
public int hashCode() {
final int prime = 31;
int result = 1;
return result;
}

@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
final TestClass other = (TestClass) obj;
if (a != other.a)
return false;
return true;
}


}

funny.. not optimal, though its perfectly legal..
hope they fix it..

 

[Ajay]

Ajay,

There used to be a website called JUnitFactory.com (I keep getting
Network time-out errors now, so maybe it is just down), that uses the
AgitarOne engine to create unit tests.  That might be closer to what
you are hoping for.

Beyond that, I have written a test harness using reflection to perform
repetitive testing of accessors and mutators.  It is not automatic,
but it does reduce a lot of the effort.

Todd

Todd, Thanks for the reply. This seems the most promising of all
replies.
I will check out JUnit Factory.

Would you be able to share your test harness? I am thinking about
doing something similar. Perhaps we could start a open source project.

Ajay

 

[Christian]

Just curious: What does it generate if the instance
variable is named `obj' or `other' instead of `a'?

public class TestClass {

byte obj;

@Override
public int hashCode() {
final int prime = 31;
int result = 1;
return result;
}

@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
final TestClass other = (TestClass) obj;
if (this.obj != other.obj)
return false;
return true;
}




byte other;

@Override
public int hashCode() {
final int prime = 31;
int result = 1;
return result;
}

@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
final TestClass other = (TestClass) obj;
if (this.other != other.other)
return false;
return true;
}

 

[Arne Vajhøj]

10 minutes per class soon adds up when you have hundreds of classes.
That's weeks of developer effort.

Considering the effort to produce the entire app, then it is small
overhead.

Any expended effort should be justified in terms of the expected value.
I don't believe that there is any measurable benefit to those test
cases, so it's still wasted time regardless of how long it takes.
>
The only bug I've ever seen in a simple getter/setter is when somebody
has hand-coded a setter like the one below and accidentally missed out
the "this".

I have seen copy paste of getters where the method name but not the
name of the variable returned was changed.

I have seen getters being removed by accident.

Time invested in unit test code is usually some of the best invested
time in a project.

Arne

 

[Martin Gregorie]

Time invested in unit test code is usually some of the best invested
time in a project.

Followed closely by the time involved in designing the application
to be testable and bugs easy to diagnose in it.

 

[Arne Vajhøj]

For me this would be extremely unlikely, because the methods are almost
always generated. Even if it did happen, it *should* become apparent in
the tests for the code that invokes the getter (assuming they are
comprehensive enough).

Sure. But that is not how unit tests are supposed to use. Each
layer should be tested independently.

Then the code that invokes the getter will fail to compile. Unless you
are accessing it via reflection, but I would hope you would have a test
for that reflection code.

No.

There are another case: if the calling code is not rebuild.

I want coverage for these methods, I just don't need to write explicit
tests to achieve this coverage. I'm sure there is some scenario that
you can come up with that wouldn't be detected by my approach but, given
that the code is auto-generated, obviously right or wrong at-a-glance,
very rarely changed, and still exercised by other tests, my experience
is that the additional benefit of explicit tests for the getters and
setters is effectively zero.

My experience is that Murphys law applies.

I don't disagree. I'm arguing that for these *trivial* getters and
setters, the testing can be bundled up in the testing of the code that
invokes them. Maybe it's not the purest *unit* testing, but I think
it's a reasonable compromise in practice.

I'll concede that there is the possibility that you have some getter
that is part of a public API (so not eligible for removal) but not
invoked by any of your code. In that case, I may consider writing a
test for it, but probably only after I notice it in the coverage report,
and only out of some obsessive-compulsive urge to get (closer to) 100%
coverage.

If I were convinced that it were necessary to test these methods in
isolation, I would look for a tool to do it automatically Which is
where we came in...

It would be trivial to write a utility that uses reflection to
find all matching get/is and set methods and test the simple
functionality.

But if some of the functionality is more complex (like set methods
that perform range checks) then that approach will not work.

Arne

 

[Christian]

And at the same time, the need for unit tests will increase sharply.

may be getters and setters should not be tested..

I could think that especially for getters and setters with range checks
or moderate complexity jml could work.
Anyone ever tried it?

Christian

 

[Christian]

may be getters and setters should not be tested..

I could think that especially for getters and setters with range checks
or moderate complexity jml could work.
Anyone ever tried it?

Christian

nah Forget that .. stupid idea .. better write the needed unit tests..

 

[Arne Vajhøj]

Calling code is always rebuilt. Maybe not immediately, but certainly
before check-in, and definitely by the CI server.

That is a special case for you - I would not assume that
to be the general case.

Arne