Looking for an intelligent tool to generate junit tests

Discussion in 'Java' started by Ajay, Jun 11, 2008.

  1. Ajay

    Ajay Guest

    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
     
    Ajay, Jun 11, 2008
    #1
    1. Advertising

  2. Ajay

    Mark Space Guest

    Ajay wrote:

    >
    > 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.
     
    Mark Space, Jun 11, 2008
    #2
    1. Advertising

  3. Ajay

    Christian Guest

    Ajay schrieb:
    > 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 ...
     
    Christian, Jun 11, 2008
    #3
  4. Ajay

    Danno Guest

    On Jun 11, 3:42 pm, Ajay <> wrote:
    > 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!
     
    Danno, Jun 12, 2008
    #4
  5. Ajay

    Ajay Guest

    On Jun 11, 8:38 pm, Lew <> wrote:
    > Christian wrote:
    > > 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.
    >
    > --
    > Lew


    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, Jun 12, 2008
    #5
  6. Ajay

    Ajay Guest

    On Jun 11, 6:00 pm, Mark Space <> wrote:
    > Ajay wrote:
    >
    > > 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.


    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
     
    Ajay, Jun 12, 2008
    #6
  7. Ajay

    Christian Guest

    Ajay schrieb:
    > On Jun 11, 8:38 pm, Lew <> wrote:
    >> Christian wrote:
    >>> 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.
    >>
    >> --
    >> Lew

    >
    > 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, Jun 12, 2008
    #7
  8. Ajay

    Christian Guest

    Eric Sosman schrieb:
    > Christian wrote:
    >> [...]
    >>
    >> 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.
     
    Christian, Jun 12, 2008
    #8
  9. Ajay

    Mark Space Guest

    Eric Sosman wrote:

    > 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.
     
    Mark Space, Jun 12, 2008
    #9
  10. Ajay

    Philipp Guest

    Lew wrote:
    > 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
     
    Philipp, Jun 12, 2008
    #10
  11. Ajay

    Todd Guest

    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, Jun 12, 2008
    #11
  12. Ajay

    Christian Guest

    Philipp schrieb:
    > Lew wrote:
    >> 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..
     
    Christian, Jun 12, 2008
    #12
  13. Ajay

    Ajay Guest

    On Jun 12, 3:04 pm, Todd <> wrote:
    > 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
     
    Ajay, Jun 12, 2008
    #13
  14. Ajay

    Christian Guest

    Eric Sosman schrieb:
    > Christian wrote:
    >> Philipp schrieb:
    >>>
    >>> 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..

    >
    > 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;
    }
     
    Christian, Jun 12, 2008
    #14
  15. Daniel Dyer wrote:
    > On Sat, 14 Jun 2008 14:47:20 +0100, Lew <>
    > wrote:
    >> Daniel Dyer wrote:
    >>> It's not laziness. It's a case of priorities. Development time is
    >>> not unlimited so I prefer to use it for something worthwhile.
    >>> Writing tedious test cases for single line getters is not the best
    >>> use of this time.

    >>
    >> That's what IDEs are good for. Writing test cases for an entire class
    >> is a work of a couple of minutes in NetBeans.
    >>
    >> Development time is not unlimited, but every place I've ever worked
    >> allows enough time in the schedule to allow the ten minutes per class
    >> it would take to write the tests for getters and setters. Your
    >> argument is specious.

    >
    > 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
     
    Arne Vajhøj, Jun 15, 2008
    #15
  16. On Sun, 15 Jun 2008 15:10:47 -0400, Arne Vajhøj wrote:

    >
    > 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.


    --
    martin@ | Martin Gregorie
    gregorie. |
    org | Zappa fan & glider pilot
     
    Martin Gregorie, Jun 15, 2008
    #16
  17. Daniel Dyer wrote:
    > On Sun, 15 Jun 2008 20:10:47 +0100, Arne Vajhøj <> wrote:
    >> I have seen copy paste of getters where the method name but not the
    >> name of the variable returned was changed.

    >
    > 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.

    >> I have seen getters being removed by accident.

    >
    > 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.

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

    >
    > 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
     
    Arne Vajhøj, Jun 16, 2008
    #17
  18. Ajay

    Christian Guest

    Lew schrieb:
    > Arne Vajhøj wrote:
    >> 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.

    >
    > 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, Jun 16, 2008
    #18
  19. Ajay

    Christian Guest

    Christian schrieb:
    > Lew schrieb:
    >> Arne Vajhøj wrote:
    >>> 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.

    >>
    >> 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

    nah Forget that .. stupid idea .. better write the needed unit tests..
     
    Christian, Jun 16, 2008
    #19
  20. Daniel Dyer wrote:
    > On Mon, 16 Jun 2008 02:53:39 +0100, Arne Vajhøj <> wrote:
    >>
    >> There are another case: if the calling code is not rebuild.

    >
    > 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
     
    Arne Vajhøj, Jun 17, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jan
    Replies:
    0
    Views:
    3,825
  2. Phillip Lord

    JUnit, writing todo tests...

    Phillip Lord, Feb 9, 2004, in forum: Java
    Replies:
    4
    Views:
    870
    Scott Ellsworth
    Feb 12, 2004
  3. Stephen Riehm
    Replies:
    2
    Views:
    750
    Stephen Riehm
    Nov 3, 2004
  4. Replies:
    8
    Views:
    910
  5. sylsau
    Replies:
    1
    Views:
    1,033
    sylsau
    Dec 12, 2007
Loading...

Share This Page