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.
Summary: | j2seproject3:junit appears to looks for tests whose name ends in Test - no way to customize pattern! | ||
---|---|---|---|
Product: | java | Reporter: | lordpixel <lordpixel> |
Component: | Project | Assignee: | Tomas Zezula <tzezula> |
Status: | NEW --- | ||
Severity: | blocker | CC: | junit-issues |
Priority: | P3 | ||
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
lordpixel
2006-05-23 15:15:18 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? 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. 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. 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? 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. 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. 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. 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? |