• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Generating JUnit Test Cases

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have heard about a program that will generate JUnit test cases by following comments that are similar in style to javadoc. I have yet to see anything about this in my searching of the web. Is there anyone whoe knows about this? If so, what's the name of the project? Where can I find more info on it?
Michael
 
tumbleweed and gunslinger
Posts: 192
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would be interested in this tool as well...
 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here is the tool you folks are looking for:
http://www.junitdoclet.org/

Happy learning.
Cheers,
Y
[ December 23, 2002: Message edited by: Yatharth Kumar ]
 
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
If you are using SUN.ONE studio you ll get a JUnit module which does this for you.
It creates skeleton for your java classes..
You can create/run the JUnit test caces here
Ajit
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It might also be good to think about whether a tool like this is actually as good an idea as it seems. I've tried both after-the-fact testing and test-driven development, and I've found the latter discipline gives you much better control over the quality of the implementation.
The kind of tool you are looking for would definitely be great for creating a test suite for a mass of source that hasn't been tested, but that isn't the same thing as making it feasible to test that source effectively.
Case in point: if you have methods that are both creating and using RMI or JDBC connections (i.e. so during testing you have little control over how those integration points are provided), you'll often run into the problem in after-the-fact test creation that it is very difficult to create repeatable tests. There can be a lot of manual fussing with your testing environment before each run, so even though the tool makes it easy to create test skeletons, it is still very difficult to have test suites that you can execute at will. End result: people stop using the test suites within a few weeks of their creation.
Of course, I can only speak to the projects I've seen. Your mileage may definitely vary.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Reid M. Pinchback:
It might also be good to think about whether a tool like this is actually as good an idea as it seems. I've tried both after-the-fact testing and test-driven development, and I've found the latter discipline gives you much better control over the quality of the implementation.


I totally agree! Test-First is also much more fun...
 
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
After looking at JUnitDoclet, it looks like it is only capable of generating skeleton code. It will not accept tags in the javadoc as directives to add "meat" to the methods. Is there an XDoclet library someone has that can generate JUnit tests? If not, JTest has a product called JContract that does this.
IMHO, this is not a difficult technology to create, has it been done before? $3K seems like a lot to pay for a technology that should be free.
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am somewhat suspicious about generating test code. First of all, it takes away a major aspect of why we're doing test-first, the design aspect. Second, how can the doclet learn enough about the test logic? Wouldn't the javadoc block become as verbose as the manually coded method body whould have?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Lasse Koskela:
I am somewhat suspicious about generating test code. First of all, it takes away a major aspect of why we're doing test-first, the design aspect.


Yep, and not only that. Writing tests also forces you to think about what you want your production code to do - and in different ways than actually writing the code.
When the journey is the reward, taking a shortcut doesn't sound very reasonable. (Hey, sounds like a good sig! )
 
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Lasse Koskela:
I am somewhat suspicious about generating test code.


I am utterly suspicious.
I'm in a situation where for new, fixed, and refactored code in our project we're slowly starting to do TDD (within a fully waterfall process). And we have also inherited a huge codebase that's not got any automated tests.
I don't see how any kind of "automated test automation" could be at all possible. The whole point of TDD is for thinking about and writing the unit tests to be the way you get quality production code, and it's the essence of why software development is a craft, not an engineering discipline.
If you could automate the creation of automated unit tests then it follows that you could automate the creation of the production code -- this is patently ridiculous and thus negates the premise
Ah, gotta go to sleep now.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First of all, I agree with the others who posted that TDD is much better than generating tests. Having said that, we use Parasoft's JTest. The product can generate junit tests (although I don't use it for that.) JTest also keeps track of some of these tests internally (not in JUnit.)
It works by creating junit tests that write asserts assuming the actual output is correct. Clearly, this doesn't serve as an actual test. But, it does flag if your output/return values differs from past results. If you consciously changed the code, you can change the test. But if you didn't know about the change, it is a useful regression test.
 
Allan Halme
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeanne Boyarsky:
It works by creating junit tests that write asserts assuming the actual output is correct.


Hmm, I don't get it. How does JTest know what to assert the expected values to be and how does it know where and what are the actual values to assert against?
Could you give a short example of a junit test method, showing what JTest has generated?
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Allan,
Suppose you have the following method

JTest will generate a test class with asserts like the following: (the code is not exact because i don't want to step on their intellectual property)

The first time, this test class will run perfectly because the expected values are taken from the acutal value returned.
Now, suppose you change the original method to return 8. The tests will fail because they are expecting 5, 4 and 12 respectively.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeanne Boyarsky:
Allan,
Suppose you have the following method

JTest will generate a test class with asserts like the following: (the code is not exact because i don't want to step on their intellectual property)


How does it come up with the test values?
If I would write a test for this method at all, I would want it to explore some boundary conditions, such as
0
-4
-5
-6
Integer.MAX_VALUE - 5
etc.
I guess that JTest would have some problems coming up with those?
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ilja,
JTest tries to use values that are normally boundary conditions (0, 1, 2, -1) and representative numbers (like 7.) The numbers aren't specifically tied to your code. That's why you should be writing JUnit tests yourself.
The idea with JTest is that if you don't have any tests at all (like when an organization starts writing tests), it is better to have this automated check than nothing.
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Lasse Koskela wrote in reply to an email mentioning JUnitDoclet:
  • Running JUnitDoclet (for the class or the package) will produce a test method like this:

  • At this point both (test and method) are empty. Now it's time to implement the test. The benefits of Test First (thinking about the method from a users point of view, ...) apply. It's just this single threaded keyboard that makes the skeleton of the application method show up first.
  • The usual "green to red" (implementing a failing test) and "red to green" (making all the tests pass), no surprise here.
  • So far there is not much of a difference to a template based approach as with Eclipse. But how about refactoring? The most frequent refactorings I do are Rename and ChangeSignature. JUnitDoclet is helping to keep tests and application in sync by regenerating the skeleton and keeping the meat. No tests get lost.

  • </ul>
    If one needs to add a test that is not related to one specific unit of code (method/class/package) it can be added too. (I'm talking about unit testing in an OOP environment. Methods are behaviour and to test behaviour I'll test method based. If you are using JUnit for other kinds of testing, JUnitDoclet can't help that much.)
    With the kind of automation provided by our tool there is always a place to put a new assertEquals statement. This way of organizing tests makes maintance easy (assuming the package struckture made sense in the first place).
    The major effects of JUnitDoclet become visible in the long run.
    Here is the major design rule of JUnitDoclet:
    Don't bother the developer with fancy GUIs, help as much as possible but don't decide anything. If there is a decision to be made the generated code won't compile at that point. The developer becomes aware of the problem and decides by making the corrections. JUnitDoclet will keep this code when regenerating.
    When someone is starting with unit testing the skeleton frees him/her from some additional "complexity". (It's not complex at all, I know. Never the less it's often used as an excuse not to unit test at all.)
    More experienced unit testers are using JUnitDoclet for a different reason: It does not distract. The focus stays on the real problem.
    Are you testing accessor methods (set/get/is)? Why not? Did you ever have a method getName returning firstName? How about generating some type based default tests for those well structured accessor methods anyway? JUnitDoclet does that. (It's not the main benefit, but it's there anyway.)
    Well, there are new features coming up:
  • Multiple test methods per application method to test different aspects seperately
  • Tests against interfaces that are applied to all implementing classes
  • ...


  • I hope this was helpful to someone.
    Kind regards,
    Steffen
    (Author of JUnitDoclet)
    [ November 29, 2003: Message edited by: Steffen Gemkow ]
     
    Lasse Koskela
    author
    Posts: 11962
    5
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks Steffen. It really clarified things for me (as well as forcing me to read up a bit on JUnitDoclet...).
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Interestingly, the way I work/think is quite incompatible to the usage of JUnitDoclet. When I start writing a test for behaviour, I often don't know which method(s) I will need. And I really like the Assert First testing pattern.
    Fortunately, my favorite IDE (Eclipse) supports this working mode really well. When I have written the calls to the methods in the test, it's a matter of a few Quick Fixes to let Eclipse generate the stubs for me.
     
    Steffen Gemkow
    Greenhorn
    Posts: 2
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Ilja Preuss:
    Interestingly, the way I work/think is quite incompatible to the usage of JUnitDoclet. When I start writing a test for behaviour, I often don't know which method(s) I will need. And I really like the Assert First testing pattern.


    I'm sure there is more than one way to do things. Just do what works best for you and what supports the kind of projects you do. If a tool does not help you, don't use it. Just don't rule it out forever because projects are different.
    Regards,
    Steffen
     
    Don't get me started about those stupid light bulbs.
    reply
      Bookmark Topic Watch Topic
    • New Topic