Using Junit plugin to generate code

Now that I have the plugin working, I'm a bit disappointed. I thought the plugin would generate a stubbed test class for a specified class including test methods for each orginal method and setup, main, etc. Instead, it seems that I have to first generate the class (by selecting CTRL T on the orginal class) and then generate each individual method by selecting CTRL T on each method. Is this correct? I was hoping the plugin would automatically create all the test methods, taking away the tedium of tracking many methods. Am I missing something or is this all it is capable of doing at this time?

17 comments
Comment actions Permalink

BTW - I have to create Junit tests for existing code, that's why I would like it to automatically generate test methods for all methods. Otherwise, I can understand the functionality of creating one method at a time so you can test as you code.

0
Comment actions Permalink

The test methods would be written one at a time anyway, so why have the
plugin generate lots of empty stubs? This would give you nothing but a false
indication of what you really test, so I think the "create only the method
you do want to fill in" approach is the right one.

Just my 2c,
Andrei

"Suzanne Dorman" <no_mail@jetbrains.com> wrote in message
news:23971119.1059063066203.JavaMail.itn@is.intellij.net...

BTW - I have to create Junit tests for existing code, that's why I would

like it to automatically generate test methods for all methods. Otherwise,
I can understand the functionality of creating one method at a time so you
can test as you code.


0
Comment actions Permalink

If I remember correctly, the plugin marks as warnings all methods in the class which do
not have corresponding test methods. You can use F2 to jump through these warnings and
create a stub for the method you want to write a test at the given moment.

IMHO the empty test stubs add no more value that the empty javadoc stubs. This way at
least you get the warning.

Sample workflow:
1. Open the tested class.
2. Create the corresponding unit test.
3. Press F2 to go to an untested method
4. Create test stub (which will take you to the test class)
5. Type in your test code
6. Use the shortcut to go to your tested class
7. Go to #2

Infact if yhe plugin did generate empty stubs, it would save you step 2 and step 7, but
then you'd still have to look for not implemented test methods in the test class.

0
Comment actions Permalink

I disagree. In this case (existing code needing tests), it's all too easy to
miss a method that really should be tested if you're going through them one
at a time. On the other hand, if you generate stubs for every method and
fill them all in with a fail() call, JUnit itself gives you a great overview
of which methods aren't being tested properly yet.

I think this would be a nice feature to have in the JUnitTestPlugin. When
creating a new TestCase class, it could pop up a dialog allowing you to
choose the methods to generate test stubs for (perhaps with all public and
protected methods selected by default). I imagine the dialog would look
similar to the dialog for the "Pull Members Up" refactoring. I'm kind of
inclined to take the plugin sources and have a go at implementing this...

Vil.

Andrei Oprea wrote:

The test methods would be written one at a time anyway, so why have the
plugin generate lots of empty stubs? This would give you nothing but a false
indication of what you really test, so I think the "create only the method
you do want to fill in" approach is the right one.

Just my 2c,
Andrei

"Suzanne Dorman" <no_mail@jetbrains.com> wrote in message
news:23971119.1059063066203.JavaMail.itn@is.intellij.net...

>>BTW - I have to create Junit tests for existing code, that's why I would


like it to automatically generate test methods for all methods. Otherwise,
I can understand the functionality of creating one method at a time so you
can test as you code.


--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

Disclaimer

This e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.

0
Comment actions Permalink

When I generate the test class, I get:

public class TestUtilFile extends TestCase
{
}

When I hit F2, I get "No errors found in this file".

I agree with Vil. It is easy to identify a test method with no test code, it is much harder to be sure you have gotten every method in the original class (especially, when it was written by someone else, hence, your knowledge of the class is limited).

0
Comment actions Permalink

Andrei Oprea wrote:

The test methods would be written one at a time anyway, so why have the
plugin generate lots of empty stubs? This would give you nothing but a false
indication of what you really test, so I think the "create only the method
you do want to fill in" approach is the right one.


They could be generated to immediately fail:

public void testSomething() {
fail("This test has not been implemented yet");
}

Thus you would get lots of failures which provides impetus to implement
the tests ;)

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: 416-643-4846 | Fax: 416-594-1919

0
Comment actions Permalink

Gordon Tyler wrote:

>

Thus you would get lots of failures which provides impetus to
implement the tests ;)



And it would take you a whole day to see the next green light.!

Alain

0
Comment actions Permalink

Thus you would get lots of failures which provides impetus to implement
the tests ;)

>

C'mon, I'm not THAT eager to write all the tests. :)

Andrei


0
Comment actions Permalink

If you are using the EAP builds that are supported, you can click on the little gutter icon and create the first test method.
In addition for both Ariadna and Aurora version use Ctrl-T (soon to be Ctrl-Shift-T for Aurora since Ctrl-T is CVS update now) to create the method.
Use it also to navigate back and forth between test and tested method.

Jacques

0
Comment actions Permalink

That is the reason there is a little gutter icon to signify that there is no test method associated to a public/protected method.
The caviat right now is that the determination is purely done through the naming patterns of class and method.

I have in the plan (when I have the time) to do a little bit of static code analysis to truely detect tests that exercise a method. However for the time being it will have to do I am afraid.

Jacques

0
Comment actions Permalink

I can see exhausting days where I would eventually just remove the fail() calls just to see the green light ;)

I believe the feedback that the gutter icons give you is enough. It isn't easy to just forget about them (that is why they are red ;)

The problem with too much failures, outside of what Alain said is that you would not see the impact of your mistake.
Impetus will be built by having a growing number of test methods that pass with no regression. You will feel good about yourself, confidence will rise gradually and in no time you will be zipping through the class.

Last and not least, this plugin won't replace the continuous use of a nice coverage tool like clover (which has a very nice plugin for Ariadna BTW).
Coverage is the best value/effort to know how much testing one is doing. My plugin won't replace that. I have been talking with the excellent Cortex guys (clover makers) and they have the vision of integrating clover with the build process so we would always know, not just what method are not tested, but also what statement/condition... (one step above their current plugin). Given the information they collect during the tests it would not be too difficult to use that info to only retest the impacted tests... ;)


Jacques

0
Comment actions Permalink

Jacques,

any plans to use the path settings to find suitable locations for test
classes? I'm referring to the Test Source Folders configured in Project
Properties > Main Module > Contents.

Vil.

Jacques Morel wrote:

That is the reason there is a little gutter icon to signify that there is no test method associated to a public/protected method.
The caviat right now is that the determination is purely done through the naming patterns of class and method.

I have in the plan (when I have the time) to do a little bit of static code analysis to truely detect tests that exercise a method. However for the time being it will have to do I am afraid.

Jacques


--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

Disclaimer

This e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.

0
Comment actions Permalink

Jacques Morel wrote:

>I have in the plan (when I have the time) to do a little bit of static code analysis to truely detect tests that exercise a method. However for the time being it will have to do I am afraid.
>


Somehow, IDEA has already made a first step in this direction in the
Code Inspection, with the addition of Junit test cases as entry points :

"Find classes/methods not used by any TestCase"
see http://www.intellij.net/tracker/idea/viewSCR?publicId=3072#228464


I wish they made the second step, and update the icon from static
analysis, as you suggested. This would be a great great great feature.


Next step :
Run only the tests that exercise a class/method
http://www.intellij.net/tracker/idea/viewSCR?publicId=8344


Test Coverage Matrix
http://www.intellij.net/tracker/idea/viewSCR?publicId=7318

Alain




0
Comment actions Permalink

Vilya,

How do you envision it working? You would still have to specify where in that source path the test classes are supposed to be and how they are named right?
Are you thinking another variable in the class pattern configuration to select that source path ?

Jacques

0
Comment actions Permalink

* Somehow, IDEA has already made a first step in this direction in the
Code Inspection, with the addition of Junit test cases as entry points :*
Interesting. It did not even occur to me to look there. I will see what I can do. I was thinking of looking at the implementation of Erb's beautify sequence plugin which does that work already.

Run only the tests that exercise a class/method
Yep it is definitively something I want to do

Test Coverage Matrix
This is a big undertaking with integration with the build process. I leave this one for the coverage professional. The Clover plugin has the beginning of this and I have talked to the cortex guys and they also want to go there. As I am sure you know Erik G and Kent B. are supposed to work on something like that in eclipse where running the tests is part of the normal incremental build. The build always run tests as part of the build and failures/errors are reported the same way as compilation errors. The build does build avoidance not only at the compilation level but at the test level as well.

Would it be nice? If only I had the time ;)

One other thing I would like to develop in the plugin is extracting as much documentation from the test methods. With a little bit of consistency tests could describe methods/classes responsability. In addition to documenting the class it would also help visualize what your tests are doing and be able to determine what you did not test faster or what tests are redundant.

Got some time after finishing playing with l'"Usine"?

Jacques

0
Comment actions Permalink

I'm not really sure. Maybe we could just specify a test path relative to the
test source root (any of them) and have a combo box to select which test
source root is used? It would certainly be nice if the test pattern could be
applied to all the test source paths that the user has added when navigating
to a test case. I guess this needs thinking about a bit more...

Vil.


Jacques Morel wrote:

Vilya,

How do you envision it working? You would still have to specify where in that source path the test classes are supposed to be and how they are named right?
Are you thinking another variable in the class pattern configuration to select that source path ?

Jacques


--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

Disclaimer

This e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.

0
Comment actions Permalink

Jacques Morel wrote:

>.. Erik G and Kent B. .. in eclipse where running the tests
> is part of the normal incremental build.


Speaking of integrating tests in the normal build/compile process, a
simple LVCS feature I miss a lot is

"Revert to last working test state"
http://www.intellij.net/tracker/idea/viewSCR?publicId=3037#446108


> One other thing I would like to develop in the plugin is extracting
> as much documentation from the test methods...

Are you sure it's worth the sweat? I feel a "simple" improvment of "Find
Usage" :
"Find usage in test cases only"
, combined with smart test methods naming, would provide most of this
service (not the global reporting though).


Imagine :

on the method "_Log.delete_"

=> used in 2 classes, 3 methods

Class TestC_LogManager
test*3_logPurge_AskedByUser *
test5_automaticLogPurge_whenDiskSpaceIsLow

Class Test_CrashRecovery
test2_unrepairableCorruptedLog



By principle, I'm always a little cautious at automated
documentation/xref/check solutions, because of the usage that some
people will make of them.. I call that :
"The Airbag Effect" :
"I drive faster because my car is equipped with an airbag"

and it's evil brother :
"I don't wear a seatbelt because my car is equipped with an airbag"

I try to reach this goal - documenting - with coherent test code
structure and "smart" test methods naming. The improved "Find Usage"
mentionned above is the missing piece here.

But true, it's not a complete solution. Some additional and
automatically produced doc/xref would help... And Clover.



> Got some time after finishing playing with l'"Usine"?

I'm still looking for the light switch :)


Alain

0

Please sign in to leave a comment.