This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 76739 - j2seproject3:junit appears to looks for tests whose name ends in Test - no way to customize pattern!
Summary: j2seproject3:junit appears to looks for tests whose name ends in Test - no wa...
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: Tomas Zezula
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-23 15:15 UTC by lordpixel
Modified: 2018-11-07 18:46 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description lordpixel 2006-05-23 15:15:18 UTC
In a standard Netbeans 5.0 project, the Ant Task j2seproject3:junit seems to
find tests by looking for all classes whose name ends in Test (**/*Test.class in
Ant terms).

Unfortunately, as with all of the other j2seproject3 tasks, there doesn't seem
to be any documentation for this task, and it is not obvious how to change the
pattern used. Our corporate standard happens to be to end the name with '_t'
(it's a C++ thing) which is obviously not working well with Netbeans 5.

Or did I miss some other way of flagging a test?
Comment 1 lordpixel 2006-05-23 15:33:00 UTC
OK.. so as always happens I figured out how to do it by overriding -do-test-run
in build.xml

(don't forget to declare the j2seproject3 namespace)

    <target name="-do-test-run" if="have.tests" 
depends="init,compile-test,-pre-test-run">
        <j2seproject3:junit includes="**/*Test.java,**/*_t.java"/>
    </target>

Shouldn't there be a property that can be set in pre-init to make this a little
simpler?
Comment 2 Marian Petras 2006-05-24 07:09:21 UTC
This is defined by the default definition of Ant macro "junit" in the project's
build-impl.xml file. You can override it by putting a modified clone of target
"-init-macrodef-junit" to the project's build.xml file.

Step-by-step:

1) Open the Files view (main menu: Windows | Files).
2) In the Files view, open (expand) folder "nbproject" under your project's
   root directory.
3) In the "nbproject" folder, open file "build-impl.xml".
4) Open the Navigator window (main menu: Windows | Navigator (Ctrl-7)).
5) In the Navigator, double-click on "-init-macrodef-junit".
6) In the editor window, select the whole target "-init-macrodef-junit"
   and copy it to the clipboard.
7) In the Files window, open file "build.xml" (located in the project's root
   folder).
8) Create a new line below '<import file="nbproject/build-impl.xml"/>'
   and paste the clipboard content there.
9) In the pasted XML code, modify line

               <attribute name="includes" default="**/*Test.java"/>

   by changing the default pattern.
Comment 3 Marian Petras 2006-05-24 07:15:35 UTC
So you found a better solution (better to override "-do-test-run" than
"-init-macrodef-junit") - good.

As for your last question, I am not sure it would be a significant benefit. Most
people do not need to change the pattern and for those who do, there is a simple
solution (as you have found).

Let's wait for an answer of the responsible developer.
Comment 4 lordpixel 2006-05-25 15:36:40 UTC
At this point it probably comes down to better documentation.
I didn't find it documented anywhere that the pattern was **/*Test, much less
how to change it. The macrodef isn't a widely used feature of Ant - I wasn't
aware of it until I looked at this.

Doing a search for j2seproject:junit (or j2seproject:anythingAtAll) produces no
useful results on the Netbeans website, but it should probably lead to a
tutorial on how to override these "mysterious" Netbeans macros. Is there a
better place to give this kind of feedback than this defect?

Of course, if one digs into the build.xml files it becomes obvious, but for a
novice who is using "Standard" projects and configures their projects through
the GUI it would be very hard to find. The balance is of course, such a user is
unlikely to need to change the pattern. The Advanced options UI has a JUnit
node. Maybe it should go in there?
Comment 5 Marian Petras 2006-05-26 06:19:52 UTC
You are right some (short) article could be written on the subject. It would be
nice if you could write one. I would then place in to the NetBeans knowledge
base or the the JUnit module's web pages (or on both places).

The JUnit node in the Options dialog is a natural location for such an option,
definitely. But to make the option working, it requires that the project type's
default build file is changed to make use of it. This is not my domain (that's
why I reassigned this issue to module 'java/j2seproject'), let's wait for more
information from Tomas Zezula.
Comment 6 Tomas Zezula 2006-05-26 08:53:04 UTC
If the JUnit module provides a public API for getting this setting (the pattern
of test files), the project types can modify the build scripts.
Comment 7 friday 2008-04-01 21:50:21 UTC
I work at a company that uses IntelliJ, Ecilpse, and Netbeans. Some test code written under IntelliJ did not work
because of this very issue. To work around this issue, the writer of the code has renamed his files and class names.

It's very bad practice for the IDE to enforce a naming convention unless it's part of the Java language. It would be
greatly appreciated if this issue was fixed. At the very least there could be an option under the JUnit settings dialog
box to deal with this.

BTW, this should be considered a bug not an enhancement as it can break working code.


Comment 8 robross0606 2018-11-07 18:46:05 UTC
I agree this is bad implementation.  Not only do these methods make assumptions about behavior with complicated and error-prone solutions, but they also don't seem to support some of the features offered by the Ant junit task.  For example, is there a way to change the fork mode with j2seproject3:junit?  Where is the documentation on this Ant task?