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.
As stated in summary, the IDE should be able to run a Java class either as a JUnit test case, or as a general Java class that has a main() method in it.
Actually, not being able to a class that has a legitimate main() method in it should be considered a defect, regardless where the class is located - test or src.
This problem does not have any easy workarounds too. If the same folder can be added as a test folder AND a source folder, that would be a reasonable workaround; the same file can be executed as a test while in 'test packages' and as a main class while in 'source packages'. But the ide does not allow a test folder to be added as a source folder too. The ide should provide a 'Run Main' menuitem for those test cases which also contain a main method.
I agree with the summary. The class can technically be a unit test and also be a main class. I think if there's a main method "run-file" should execute that class as a Main class, and if the class extends TestCase, or has the JUnit annotations, you should have a separate option "run-test" to run the class as a unit test.
Invocation of tests is handled by the projects infrastructure - reassigned to component "projects".
I think, too, that one should be able to run a (eg. non-unit) test class with a main method.
I think my preferred solution would be to have another directory, like the test directory, which would not be compiled in the distro. I don't want the test source classes intermixed with my project sources, but I do want access to the package-private methods. Making a separate project actually works pretty well, however to run my tests it has to build my main project's jar file first. This is quite a time-waster for me. I have the automatic packaging turned off since I have a custom mechanism I use when building a distro. However, running a project that depends on another forces the packaging. Normally when I am developing / testing, I just skip this packaging step which saves me a lot of time. If having a dependent project didn't force it to package that project, I would be satisfied with just putting the files in an extra project. However, what would be ideal for me is if I had a directory for my "runnable" tests that would compile its classes to a separate directory (like the junit test files do). They would not get packaged, the main project's jar file would not need to be built, I could access the package private methods, and the sources for the tests would not be mixed in with the junit test sources or my project's sources. Perfect.
the infrastructure could possibly just provide the action "run as test" that would appear on the file's popup, then a "debug as test" is also necessary. And we have to deal with the main menu's "Run File", "Test File" Items. The current behaviour is the for test files the "Test File" action is disabled and only "Run File" enabled. For main project sources "Test File" will run the appropriate test file (if any). If we change that to "Test File" always meaning run junit, and "Run file" meaning run via main(), then it should be fairly easy. However that's a change in UI behaviour and shall be discussed with HIE.
Yes, yes, yes, that would be great. Even if the current behaviour is "more correct" in some theoretical sense, the proposed behaviour would better meet the user's expectations and match more common use cases.
The proposed change makes sense to me. It's probably better if the same action (and shortcut) is used for launching tests, no matter whether the selected file is a regular class or test class. Currently that's not the case which also means there's no way to run main method in a test class. Just to make sure I understand the proposal, here's how I see it: --- Run File - runs the main method Test File - runs the selected test class or the associated test class for the selected regular class --- --- Debug File - debugs the main method Debug Test File - debugs the selected test class or the associated test class for the selected regular class --- I'm fine with such change.
jrojcek: thanks for the comments.
*** Issue 116211 has been marked as a duplicate of this issue. ***
done for j2se and maven projects. I've tried to check web/j2se projects as well, but got lost there. Reassigning to web project to reimplement run/test single file in the same way..
Integrated into 'main-golden', will be available in build *200810240201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/ea79749c1951 User: Milos Kleint <mkleint@netbeans.org> Log: #119922 change semantics of Run file for tests, allow running test classes witn main() method.
*** Issue 153145 has been marked as a duplicate of this issue. ***
I am a little confused by this issue. If I am understanding the comments correctly it sounds as if the test case also has a main method that there should be 4 menu items to execute the class. The user should be run/debug the class as a regular java class or as a Unit test. However while trying to understand I have noticed that J2SE project only have 3 menu items to execute a test case with a main method. Instead the class only has a Run File, Debug XXX.java (which I also wonder why the naming convention is not the same between the run and debug menus), and Test File. The Debug Test File action is missing.
this is not about the popup of the project type. But the actions in main menu and the java file popup. Main menu has "run file" and "test file" in Run menu, and Debug File and Debug Test file in Debug menu. for you it means rewriting the ActionProvider implementation in web projects to have the RUN_SINGLE action always to run vai main(). Currently it's not the case, as for test sources it will run the test as testcase.
Integrated into 'main-golden', will be available in build *200811251401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/2458060c44b4 User: Milos Kleint <mkleint@netbeans.org> Log: #119922 Test File belongs on the java file's popup.
http://hg.netbeans.org/main/rev/81dcc4b6313d At least a partial checkin.
I understand that this issue not about the actions on the project node. I was talking about the actions on the file node. On the file node the action Debug Test is missing. This is true for both the java project as well as the web project.
Last check in http://hg.netbeans.org/main/rev/5ee4c44c6b7b
When the run or debug actions are executed on a class that does not have a main method a dialog will now notify the user about the missing main method. http://hg.netbeans.org/main/rev/67c7ee5719ad
question to the previous comment: If the class does not have a valid main or test method, why would the user ever gets a change to choose "run file" or "run test"? In that case, the run-test/run-file option should not appear on UI in the first place. Unless, the pop-up window also provides meaningful functions, like: auto-generate a runnable main method, convert current class into a JUnit test class,.....
See issue 158068, reopening. ------------[ from issue 158068 ]------------ OK, just a few notes to explain why I am reopening this issue (with different summary): 1. This is a UI change - it should have gone through the review process (see link above) and UI specification (also above) should have been updated to reflect this behaviour. 2. There is no "debug test" in file's context menu - I have lost a convenient start point for debugging a JUnit test. I have to use the main menu or a shortcut, which is not so nice as the invocation from the context menu (when I invoke the context menu above a file, I know the action is really invoked for the file I want). 3. I cannot run/debug a normal test (AND THIS IS WHAT YOU DO IN 99%!!!!) from the editor's context menu as there is no item for it - but if the test by the accident had a main method (for some probably very clever reason), I can run it... cool... 4. A little bit of linguistic jam... What is the logic behind this: "Test file" invoked above a JUnit test class runs the test... ? IMO "Test file" invoked above JUnit test should run the test for that test. "Run Test" would make much better sense than "Test File"... "Test file" makes more sense above the class it is supposed to test => please at least change the actions name to "Run Test" and "Debug Test" (and update UI spec accordingly). So basically: we introduced several PITA issues (2,3) just because we wanted to allow someone to run main method from the file that is technically a JUnit test... ??? Now I will be maybe little stupid: What is a ratio behind having a JUnit test as a main class anyway??
Closing again as the originally (and often) requested feature is now implemented. joshis you should file blocking issues for points #2 - #4.
*** Issue 43391 has been marked as a duplicate of this issue. ***
joshis: To address your question "we wanted to allow someone to run main method from the file that is technically a JUnit test... ??? Now I will be maybe little stupid: What is a ratio behind having a JUnit test as a main class anyway??", issue 43391 has a couple of other use cases that make this desirable. Essentially, not every type of "test" that people want to run is going to be a JUnit test, but putting them in the "Test packages" folder has perviously meant they could only be run with the junit test runner. Putting them in "Source packages" is undesirable since they are then packaged into the application's jar/war/etc. Perhaps the folder should have been named "JUnit Test packages" in the first place, and instead you'd be getting enhancement requests to support additional test types & frameworks :-) But at least if executable test classes (with a main method) can be run as such, they can be be kept separate from the main code in the project subdirectory where they intuitively belong. It may still take a bit of hacking in the build.xml overrides to have them all run automatically during the "test" target, but it's an improvement.
Also for autoproject and freeform samples: contrib #e037ae2a6910
*** Issue 56634 has been marked as a duplicate of this issue. ***