UnitTest: features I could really use

hi.

I love this plugin! But a I have been using it more recently I have found some issues:

-Project level settings aren't enough. I have different modules which for legacy reasons have tests in different places.

-I would like to be able to use multiple Class Suffixes. We don't only use the standard <classname>Test.java pattern

-I often want have many test methods for any one method. It would be nice if when pressing ctrl-alt-T there was a choice window asking which method to go to. This would assume that all test methods followed a simple pattern like:

MyClass.parse()
MyClassTest.parseTest()
MyClassTest.parseValidationTest()
MyClassTest.parseBoundaryTest()
MyClassTest.parseExceptionTest()

I do this so that tests that fail do not hinder other test being run.

Florian Hehlen

22 comments
Comment actions Permalink

The good news is all these is already in the plan and should be the very next things to be done.
The bad news is we have no time right now.

Jacques

0
Comment actions Permalink

Where can one find instructions on the use of the JUnitGenerator plugin? I installed it and the only change I could determine was an additional item "Unit Test" in the right-click Generate... menu.

When I select that item nothing seems to happen.

Brian

0
Comment actions Permalink

Wrong plugin. There are 2 plugins for unit tests generation. They differ in their fundamental approach:
1. JUnitGenerator generates an entire test class with one test method per public methods
2. UnitTest generates the test class and test method on demand.

You can also use them both.

Jacques

0
Comment actions Permalink

UnitTest is a terrific plugin!

It's version is only 0.25. What features are planned for its future?

Brian

0
Comment actions Permalink

I have been using http://www.intellij.org/twiki/bin/view/Main/JUnitTestPluginRequests

But what would you like the plugin to do?

0
Comment actions Permalink

I don't promise anything. I am on so many front that I haven't made any priority decision yet.
This is what I propose for the

Multi test support:
You are on a tested method. Ctrl-Shift-T popup a selection menu (like the template selection menu) like this
|1 testMethodFirstCase |< |2 testMethodSecondCase | |3 testMethodThirdCase | |4 testMethodFourthCase | |-------------------------| ]]>
On top of the menu you will find a option box to turn on/off the test method name translation into english (like the TestDox plugin does). Turn it on and you would see
|1 First Case |< |2 Second Case | |3 Third Case | |4 Fourth Case | |-----------------------| ]]>
The last visited test method would be by default selected so you can switch back and forth with Ctrl-Shift-T + Enter or Ctrl-Shift-T twice.

From the test class it would do the same with an additional preselected item to go to tested method
|1 Tested method |< |2 First Case | |3 Second Case | |4 Third Case | |5 Fourth Case | |-----------------------| ]]>

Multi pattern support:
First phase: we can enter multiple pattern from the configuration. Each pattern would have an optional name used to prefix the menu test name:

|1 Tested method |< |2 Unit: First Case | |3 Unit: Second Case | |4 In container: First Case | |5 In container: Second Case| |-----------------------------| ]]>

Second phase: the patterns are just used to create a prototype. The plugin will seach any test class in the target directories of the pattern and pick up test cases in any test class that reference the tested method.

Third phase: Support for incremental test run i.e. run the tests that gets affected by a change. Using the compiler open api, instrument the classes to maintain a tested method->test methods graphs. The graph would be constructed on the first full test run. Once done the graph would be updated each time a test is run. The patterns would only be used for creation/maintenance. Obviously I haven't a clue of the performance of such a beast. It is just a nice idea I have. Maybe the good folks at thecortex (clover) will implement this before I get to.

Jacques

0
Comment actions Permalink

Hello Jacques,

I like it. I was just writing some tests today where I had multiple test methods for one "real" method. I was thinking of submitting a feature request just like this. I'm glad to see you're one step ahead.

Tobin

I don't promise anything. I am on so many front that I haven't made
any priority decision yet. This is what I propose for the

Multi test support:
You are on a tested method. Ctrl-Shift-T popup a selection menu (like
the template selection menu) like this
|-------------------------| > | O Display in english | > |-------------------------| > |Spc New test case | >> |1 testMethodFirstCase |< >> > |2 testMethodSecondCase | > |3 testMethodThirdCase | > |4 testMethodFourthCase | > |-------------------------| > ]]>
On top of the menu you will find a option box to turn on/off the test
method name translation into english (like the TestDox plugin does).
Turn it on and you would see
|-----------------------| > | X Display in english | > |-----------------------| > |Spc New test case | >> |1 First Case |< >> > |2 Second Case | > |3 Third Case | > |4 Fourth Case | > |-----------------------| > ]]>
The last visited test method would be by default selected so you can
switch back and forth with Ctrl-Shift-T + Enter or Ctrl-Shift-T twice.

From the test class it would do the same with an additional
preselected item to go to tested method
|-----------------------| > | X Display in english | > |-----------------------| > |Spc New test case | >> |1 Tested method |< >> > |2 First Case | > |3 Second Case | > |4 Third Case | > |5 Fourth Case | > |-----------------------| > ]]>
Multi pattern support:
First phase: we can enter multiple pattern from the configuration.
Each pattern would have an optional name used to prefix the menu test
name:
|-----------------------------| > | X Display in english | > |-----------------------------| > |Spc New test case | >> |1 Tested method |< >> > |2 Unit: First Case | > |3 Unit: Second Case | > |4 In container: First Case | > |5 In container: Second Case| > |-----------------------------| > ]]>
Second phase: the patterns are just used to create a prototype. The
plugin will seach any test class in the target directories of the
pattern and pick up test cases in any test class that reference the
tested method.

Third phase: Support for incremental test run i.e. run the tests that
gets affected by a change. Using the compiler open api, instrument the
classes to maintain a tested method->test methods graphs. The graph
would be constructed on the first full test run. Once done the graph
would be updated each time a test is run. The patterns would only be
used for creation/maintenance. Obviously I haven't a clue of the
performance of such a beast. It is just a nice idea I have. Maybe the
good folks at thecortex (clover) will implement this before I get to.

Jacques


-- Posted by JetBrains OmniaMea

0
Comment actions Permalink

I love the way a little icon appears in the gutter (is that the word?) to indicate a method does not have a test and clicking on it automatically makes a skeleton test for the method.

A nice feature would be some way to jump to the test for the methods which DO already have a test written. Perhaps a different icon or maybe a rightclick item while on the method. (Note: The first entry in the WIKI describes such a feature and it is marked as DONE but I don't see it.)

Brian

0
Comment actions Permalink

I think Ctrl+T does this.

"Brian K. Buckley" <briankbuckley@comcast.net> wrote in message
news:32323072.1086782714976.JavaMail.itn@is.intellij.net...

I love the way a little icon appears in the gutter (is that the word?) to

indicate a method does not have a test and clicking on it automatically
makes a skeleton test for the method.
>

A nice feature would be some way to jump to the test for the methods which

DO already have a test written. Perhaps a different icon or maybe a
rightclick item while on the method. (Note: The first entry in the WIKI
describes such a feature and it is marked as DONE but I don't see it.)
>

Brian



0
Comment actions Permalink

Control - Shift - T !!

It's already there! Thanks.

Brian

0
Comment actions Permalink

In order produce a more completed skeleton test case for a method, I would like to have return type information available for use in the test template. Also the static/non-static status of the method.

For example if class Foo has a method mybar() that returns a Bar, I'd like the skeleton test method to include the line

Bar bar = foo.mybar(); (or "Bar bar = Foo.mybar();" if the method is static)

Currently one must manually put in the "Bar bar = " part, and manually handle static/non-static cases. This can/should be automated by the plugin.

Or is there a way to do this right now?

Brian

0
Comment actions Permalink

Unfortunately there isn't a way now.
Could you please add this request to http://www.intellij.org/twiki/bin/view/Main/JUnitTestPluginRequests

I am not sure if I can sneak it in since it is relatively small but I want to track it.

Thanks

Jacques

0
Comment actions Permalink

Brian seemed to have the same problem I am having now. JUnitGenerator gives me the "Unit Test" option when I do a Code-->Generate (along with the ususal "Getter," "Setter," etc.), but when I select "Unit Test," nothing happens.

Do I need to edit any of the files in the resources dir?

Thanks.

0
Comment actions Permalink

Sorry but this is not the right plugin. This is the unitTest plugin not the JUnitTestGenerator

Jacques

0
Comment actions Permalink

I never did figure out the JUnitGenerator plugin. As with your experience, selecting "Unit Test" doesn't seem to do anything.

Brian

0
Comment actions Permalink

OK, I am using the UnitTest plugin, and I see the Go To>Test Class and Go To>Show Tested Methods menu items. However, when I select either choice or use the corresponding key strokes, nothing happens. Is there anything I need to do beyond simply expanding the zip file?

Thanks very much.

0
Comment actions Permalink

What version of IDEA and the plugin are you using?
Can you try from both a tested class and a test class?
Have you picked in the configuration panel your naming pattern?

Jacques

0
Comment actions Permalink

I've met similar thing.
Today afternoon, I put the unitTest.jar into plugins dir.
I saw the "Test Class" and "Show Tested Methods" in the ]]> menu, and found the unitTest button in settings panel.

But as other one has pointed, neither menu nor shortcut key worked. and I noticed that if I changed the setting, then click the ok button, the setting dialog wouldn't close, I can only click "Cancel" to exit when setting changed.

I use the IDEA 4.0.3 build 1182

this bug make me haze. Thank you!

0
Comment actions Permalink

Until this matter is resolved in the plugin manager the safest way to get the 4.0 plugin is to download and manually install the version 0.25 from http://www.intellij.org/twiki/pub/Main/JUnitTestPlugin/unitTest.zip

The install instructions are at http://www.intellij.org/twiki/bin/view/Main/JUnitTestPlugin

Thanks

Jacques

0
Comment actions Permalink

WoW! Thank your clew. the plugin works now.
It's a great tool for junit-fans.

Thanks! _

0
Comment actions Permalink

OK, I got it going. Is there a way to set things up so that the test class generated contains empty implementations of test methods for all the public methods of the tested class? I am aware that such a thing should be unnecessary if one follows the strict tenets of test-driven development, but as someone trying to evolve to that level of discipline, I feel such a feature would be helpful to me.

Thanks.

0
Comment actions Permalink

Sorry for the late response but I am in vacation ;)

This is the old debate of whether to generate a complete test class shell or create each test method incrementally. The philosophy behind what you are asking is different then the one behind the unitTest plugin. The approach you mention is I believe the one of the JUnitGenerator plugin.

However I would like to hear why you think you need it.
In my experience:
1. Qe rarely have the time to completely cover ALL public methods of a non tested class.
2. Are all public methods worthy of isolated unit testing?
3. Shouldn't I apply ROI on testing so I test first the most critical, most complex code first regardless of what class it is in?
4. What should be the generated test method body? an fail()? But then that would mean a red bar until EVERY method is covered. I would lose the green-red bar cycle/feedback. I also could not check in anything until I am done with my test job.

So instead the plugin is giving you feedback of what is not tested (gutter icons, list of not tested methods) and it allows you to create test methods incrementally. The additional effort is minimal IMHO.
But prove me wrong and you may get your feature ;)

0

Please sign in to leave a comment.