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.
Tested with NB200405161800, JDK 1.4.2 In the test packages, I have a lot of JUNIT test classes, but also other NOT JUNIT test classes. And I can't run it because the Run, Run other, Run File is disabled. Any advice ?
I guess Run File in j2seproject is only implemented for src/ not for test/?
Yes. I will fix that.
Question is: should the classpath for class execution from test subdirectory contain junit.jar or not? Btw. the same case is debug-single which I will fix as well.
I will answer this myself: Yes. Java source which is not JUnit source and which is located under test directory has to use classpath which contains: - run.classpath - build.test.classes.dir - libs.junit.classpath Instead of defining new separate classpath I would simply reuse run.test.classpath for this. This is simple to do, but means some conditional logic in action provider and dedicated targets like "run-single-from-test-folder" and "debug-single-from-test-folder". So before I commit this I have sanity check questions: do we really want to support this? What is the use case? What is the usefulness of putting some classes into test directory? Should not test subfolder contain only unit tests? Or should not be these main classes executed throught some unit test or converted to be unit tests? Do we want to encourage users to do this by implementing this issue? Whoever has an opinion on this, please speak up.
CCing Jesse.
For J2SE project, yes junit.jar would be present. It's the de facto standard. But please, permits also to execute classes having main methods. For Web Projects, maybe add httpunit or http://jwebunit.sourceforge.net/ along junit.jar. And why not add jellytools/jemmy for Swing Applications ?
Vincent, please comment also my other questions. What are you solving by having these main classes which are not unit tests in test folder?
Re. conditional logic in action provider - sure, same as we already have for Compile File. I don't have a strong opinion on this one. Seems harmless, though I agree that it is not ideal to encourage users to put non-JUnit-format tests into the tests folder. Presumably in some cases you have mostly tests plus a few demo scripts or performance measurement drivers etc.? I don't know, would like some more info from Vincent on this. Provisionally marking as an RFE since the current behavior is I think as designed. Re. HTTPunit, Jelly, etc. - completely unrelated, please keep it out of this bug report. (Probably the web project type will have HTTPunit support at some point, but I don't know more about it than that.)
In fact, they are unit tests, but they are not based upon junit framework. I have 90% of my test cases written with junit. Somes others are written with dbunit. And DBUnit tests is not exactly the same as junit. So DBUnit can't be launched by just clicking CTRL-F6. Reason is that when I click on Ctrl-F6, the build.xml is calling junit task. But DBUnit tests need to be launched by dbunit task. So, my first idea was to add a main method in my dbunit class to be able to launch it. I expected that by having a main method, I would be able to launch my db unit tests. Because it is not the case, I have to search how I can easily add a dbunit task in the build.xml and execute it from the IDE. I hope that I answered to your questions. Please let me know if it's not yet clear
"Reason is that when I click on Ctrl-F6, the build.xml is calling junit task. But DBUnit tests need to be launched by dbunit task." - so that is more the issue; you should probably be editing build.xml to invoke <dbunit> where appropriate rather than cluttering the test sources with main methods. Of course adding the main methods might be the quickest workaround (assuming you have a fairly small number of such tests).
Unless there are compelling usecases this is WONTFIX for me. But I leave this open.
I don't know, I would rate it a +0 - potentially useful in some cases; not aligned with the intended usage of the project type, but mostly harmless if not used. I am mainly concerned about users attempting to run real JUnit test classes via the main method and not understanding that Run Test works correctly for any test case.
If NB will not support classes having main methods in Test Packages, why let user choose between Test and Source Packages. When I use the New Wizard, for Junit Test classes, they will be automatically created into the Test Packages. Impossible to choose between Source Packages and Test Packages. That's the expected behaviour. But when I use the New Wizard, for Java Main Class, I can choose between Source Packages and Test Packages. If Main Classes are not supported in Test Packages (I suppose it's the same for Applet, JApplet, JApplet Form, ...)why then let user choose between Source Packages and Test Packages if he can run them ?
I don't think we have any plans to make choice of template sensitive to the particular source group within a project, at least not for D. Would be nice, but gets a bit complicated.
*** Issue 49028 has been marked as a duplicate of this issue. ***
I created 49028. In my case, my main()'s create a simpler GUI for me to display a 3D Model (using Java3D) that gets read in from a file and post processed. One test program excercises the file reading/displaying classes, and the other excercises the postprocessing (combining adjacent triangels into triangle strips etc.) routines. Displaying these results in a GUI is the best test method that I have found yet, and I just haven't found the time to investigate how to use Junit to do this. Junit may be the best thing since sliced bread, but my project is small , and so far I haven't needed it yet. I think the idea of splitting out the test sources so that they don't get packed in the application is great. So far though, it's a real shame that it's been declared off limits unless the user wants to learn and use Junit. I also keep a few other programs in this area that were written as simplified test cases for the J3D team to use to find bugs I filed. Technically they don't test parts of my project, but they also aren't part of my project either. At the same time this was the project that I found thos bugs with, and this is where I"ll remember to look for that code when I need it again for some reason.
BTW simplest workaround: public class X extends TestCase { public static void main(String[] x) {...} public void testIt() { main(null); } }
Is Run File in j2seproject even implemented for src? I am running 4.0 Beta 2 (build 200409220845) and the Run File option is not enabled for _any_ class in the src module of my j2seproject. I installed RC1 (build 200411231853) and imported my settings, and same thing. Everything under the Run Other menu is disabled.
Works fine for Source Packages. You have to select the java file which has the class with main method.
Sorry, I meant j2eeproject, not j2seproject.
Don't know about Run File in j2eeproject but feel free to file an RFE (component: j2ee).
*** Issue 57277 has been marked as a duplicate of this issue. ***
Quick recap of (my) #57277 use case - in addition to my JUnit tests for correctness, I have some other (Main) classes which do various timings to compare two alternative algorithms in the code being developed. If I include them under "Source Packages" then they automatically get included in the built jar, which I don't want as they're purely for testing. But if I include them under "Test Packages" it tries to run them as JUnit tests even though they're not named *Test.java (they're *Timer.java), don't extend TestCase, and don't have any setup/teardown/test* methods. There's a couple of alternative workarounds - put them under Source and use the Packaging "Exclude from JAR File" filter to stop them being included in the jar, or (as Jesse suggested previously) convert to JUnit tests which call the main(String[]) method. From the perspective of a NB user, however, I don't see why either workaround should be necessary. Jesse, you say that you are "mainly concerned about users attempting to run real JUnit test classes via the main method". However, the fact these bug reports are being raised would suggest that the current behaviour is equally confusing - users are attempting to execute Main classes via the JUnit runner... If I create a project using an existing Ant script, I can specify classpath settings for each folder of packages. Perhaps the answer is to allow something similar in the other project types (hidden behind an Advanced Settings checkbox if you like) i.e. allow the Compile & Run classpaths and Ant targets to be specified for each folder, rather than the type as a whole? That way we could create additional folders for other test types which call dbunit/httpunit/jemmy/main() etc. as appropriate.
Re. last paragraph - it's possible, but there's no one to work on it for the time being.
Another use-case: stress tests. I have tried to put them under "Sources" and exclude the classes from the Jar, but that also leads to the classes not being displayed in the projects window. This is really test code and should go under test packages. Ideally it should even be possible to start the stress test in its own JVM.
Looks like this was already fixed under a different issue. *** This issue has been marked as a duplicate of 119922 ***