[ANN] JUnitTestPlugin 0.10 available

http://www.intellij.org/twiki/bin/view/Main/JUnitTestPlugin


0.10 (#809) - 03 Apr 2003

a.. Annotate untested methods with little red icon in the editor left gutter (Special thanks for Bronwen Cassidy to make it work)
b.. NOTE: if you get a NPE while renaming/moving a class that seems unrelated to the plugin please turn off the automatic refactoring and see if it fixes the exception. If not restart IDEA. The next release will address this.

20 comments

Is it possible to specify multiple test patterns? We have several (well,
many) source directories in our project, a few with slightly
off-standard naming. When I used the plugin in the past, I had to choose
just one directory, leaving all others to manual switching. Does this
make sense?


Jacques Morel wrote:

http://www.intellij.org/twiki/bin/view/Main/JUnitTestPlugin


0.10 (#809) - 03 Apr 2003

  • Annotate untested methods with little red icon in the editor left

gutter (Special thanks for Bronwen Cassidy to make it work)

  • NOTE: if you get a NPE while renaming/moving a class that seems

unrelated to the plugin please turn off the automatic refactoring
and see if it fixes the exception. If not restart IDEA. The next
release will address this.


0

Does this work only with Aurora?

0

Hi,

I love your plugin.
Just one point: Could you reorganize your sources. I downloaded the sources but it is nearly impossible to compile them... ;)

0

One of the task is to back port the plugin to 3.0
Look at the wiki page for the request page (http://www.intellij.org/twiki/bin/view/Main/JUnitTestPluginRequests) and add yours and vote for the ones already there. However you should still post when you do since I am not monitoring the page every day.

0

Not right now but there is a request for that(http://www.intellij.org/twiki/bin/view/Main/JUnitTestPluginRequests). Vote for it.

This is what I had in mind: we need this for migration purpose. We will be able to specify:

  • 1 current pattern always used to create new test class.

  • n patterns to navigate to already existing test class not yet on the standard.


This doesn't address the problem of a pattern per root. Do you need this?

Jacques

0

Try it again. I didn't include a build.properties in the src zip. I have updated it accordingly.
Now you should just have to change build.property under JUnitTestPlugin and run any ant target like deploy in that directory.

Jacques

0


Jacques Morel wrote:

Not right now but there is a request for that(http://www.intellij.org/twiki/bin/view/Main/JUnitTestPluginRequests). Vote for it.

This is what I had in mind: we need this for migration purpose. We will be able to specify:

  • 1 current pattern always used to create new test class.

  • n patterns to navigate to already existing test class not yet on the standard.


This doesn't address the problem of a pattern per root. Do you need this?


Well, creation of test cases is much less common than navigation of
course. But if creation (at the test or Test level) is only supported
for one path, then again one path will have to be special and all others
will need to managed manually.

Why would it be easier/better to only create from a single pattern?

0

It was to institure a standard organization of tests. This usually increase readability and simplicity (no going around trying to find a test, build file easier...).
You would still be able to do
c:/project1/src/com/foo/MyClass.java -> c:/project1/test/com/foo/MyClassTest.java
c:/project2/src/com/bar/MyOtherClass.java -> c:/project2/src/com/bar/test/MyOtherClassTest.java
<=>
project1/src/$PACKAGE$/$CLASS$ -> project1/test/$PACKAGE$/$CLASS$Test
project2/src/$PACKAGE$/$CLASS$ -> project2/src/$PACKAGE$/test/$CLASS$Test

Anyway could you provide examples so we can make sure we support your case?

Jacques

0

Other question: when Modules are in IDEA would you have the need for more than one pattern per modules? I am trying to understand how your software evolved to be using multiple test organization. Is it because they are different products/components, developed by different people?

Look at http://www.intellij.net/forums/thread.jsp?forum=22&thread=23952&message=452340&q=4d6f64756c6573#452340 for a preliminary definition of Modules

0

Modules would cover most cases. But we also use an idiom that seperates
api class from impl classes. eg,

src/api/com/...
src/impl/com/...
test/unit/api/com/...
test/unit/imp/.com/...

We do this because we build a product with many servers and many
clients. The clients only depend the api classes; the servers depend on
both. We /could/ package the api classes into a seperate jar, but that
makes it much harder to refactor.

Similarly, we have many components, each of which has its own source
root (ie, with src,test,resource,etc directories). In our idea projects,
we tend to include the maximum code/modules, leaving the management of
components to the ant tasks.

Probably modules will cover the second of these cases, but not the api/src.

Am I making sense?

Jacques Morel wrote:

Other question: when Modules are in IDEA would you have the need for more than one pattern per modules? I am trying to understand how your software evolved to be using multiple test organization. Is it because they are different products/components, developed by different people?

Look at http://www.intellij.net/forums/thread.jsp?forum=22&thread=23952&message=452340&q=4d6f64756c6573#452340 for a preliminary definition of Modules


0

Do you realize that your configuration is already supported by one pattern?
src/$PACKAGE$/$CLASS -> test/$PACKAGE$/$CLASSTest

Maybe I need to find another name for $PACKAGE$ but it is in fact the longest directory path that will match whether it is a package directory or not. Maybe it should be called $DIR_PATH$ or $DIRECTORIES$ or $PATH$.

Let me know what you think and if I misunderstood you.

I have only seen usage for multiple patterns for migration: some of our teams were using
src/$PACKAGE$/$CLASS -> test/$PACKAGE$/$CLASSTest
to go to
$PACKAGE/$CLASS -> $PACKAGE$/test/$CLASSTest
In this case they need more than one pattern but only one "creation" pattern is active at any time. The other is only to navigate.

Jacques

0

Sorry wrong pattern!
It is more like src/$PACKAGE$/$CLASS -> test/unit/$PACKAGE$/$CLASSTest

0

Where I work, we tend to have one source directory but a number of different
test directories. We split the tests out into standalone unit tests, unit
tests which require deployment into a container, and integration tests. The
directory structure looks something like:

]]>/
src/ - the source directory
test/unit - the standalone unit tests
test/deploy - the in-container unit tests
test/integration - the integration tests

It would be great if this could be supported. I'd imagine it working in the
same way as IDEA handles creating a new class when there are multiple source
paths defined: pop up a list of directories where the test class could be
created (when creating a new test class), or a list of available test
classes when navigating. You'd need to have two separate actions for test
class creation and navigation though, instead of having them combined into
one. Maybe CtrlT for navigating to the test class/method, and CtrlShift+T
for creating a new test class? If the navigation action defaulted to
creating a class when no existing test class could be found, the current
behaviour would be maintained. Thinking out loud now; I'll have a dig
through the plugin sources when I get a chance and see if I can make a more
practical contribution.

Vil.

Jacques Morel wrote:

Do you realize that your configuration is already supported by one pattern?
src/$PACKAGE$/$CLASS -> test/$PACKAGE$/$CLASSTest

Maybe I need to find another name for $PACKAGE$ but it is in fact the longest directory path that will match whether it is a package directory or not. Maybe it should be called $DIR_PATH$ or $DIRECTORIES$ or $PATH$.

Let me know what you think and if I misunderstood you.

I have only seen usage for multiple patterns for migration: some of our teams were using
src/$PACKAGE$/$CLASS -> test/$PACKAGE$/$CLASSTest
to go to
$PACKAGE/$CLASS -> $PACKAGE$/test/$CLASSTest
In this case they need more than one pattern but only one "creation" pattern is active at any time. The other is only to navigate.

Jacques


--
Vilya Harvey, Consultant
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


Vilya Harvey wrote:

Where I work, we tend to have one source directory but a number of
different test directories. We split the tests out into standalone unit
tests, unit tests which require deployment into a container, and
integration tests. The directory structure looks something like:

<projectname>/
src/ - the source directory
test/unit - the standalone unit tests
test/deploy - the in-container unit tests
test/integration - the integration tests


Thanks for bringing this up. We have exactly situation. I like the popup
idea for handling multiple matches.

0

I certainly did not. I thought that $PACKAGE$ corresponded to just the
java package.

I agree, a better name is needed.

I'll give a test.

0


Barry Kaplan wrote:

I certainly did not. I thought that $PACKAGE$ corresponded to just the
java package.

I agree, a better name is needed.

I'll give a test.


Whoops. Can't do that. I still having too many blockers with the eap.

0

You should be able to do that with the 0.4 on Ariadna.

0

Sounds good. You have convinced me that we need to support it. However this has significant usability issues. I propose that we incrementally move towards this support. What you are proposing is far more complex than what we have right now. So let's implement other features that will incrementally build the plugin up closer to your proposed feature:
1) navigation to test methods popup a pick list of methods
2) multiple test class support
3) multiple patterns with support for only one creational pattern (my original requirements)


After we have these we should be able to see in a much clearer way how we should implement the multiple creational test patterns feature. We will have navigation with multiple patters using list of multiple classes/methods... We will only have to add the ability to create multiple classes

In the meantime could you research how you are working right now. Are you using all patterns simultaneously? What are your different goals?

As usual I am welcoming any help. Bronwen Cassidy was nice enough to help already. Plus my involvement for the next 2 weeks will be somewhat limited (my wife is having our second baby tomorrow ;)

0


Jacques Morel wrote:

Sounds good. You have convinced me that we need to support it. However this has significant usability issues. I propose that we

incrementally move towards this support. What you are proposing is far more
complex than what we have right now. So let's implement other features that
will incrementally build the plugin up closer to your proposed feature:

1) navigation to test methods popup a pick list of methods
2) multiple test class support
3) multiple patterns with support for only one creational pattern (my original requirements)


OK, that sounds sensible, I'll see what I can do...

After we have these we should be able to see in a much clearer way how we should implement the multiple creational test patterns feature. We will have navigation with multiple patters using list of multiple classes/methods... We will only have to add the ability to create multiple classes

In the meantime could you research how you are working right now. Are you using all patterns simultaneously? What are your different goals?

As usual I am welcoming any help. Bronwen Cassidy was nice enough to help already. Plus my involvement for the next 2 weeks will be somewhat limited (my wife is having our second baby tomorrow ;)


Congratulations Jacques!

Vil.
--
Vilya Harvey, Consultant
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

There is a bug when you try to create test method for an overloaded method.
Plugin tries to make second test method with the same name that causes error. Try to make test from the following class to repeat this error:

public class Crocodile {
public static void hello(String a) {
System.out.println("Hello: " + a);
}

public static void hello(int b) {
System.out.println("Hello: " + b);
}
}


0

Please sign in to leave a comment.