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.
If you create a module vs. a regular project and you want to create tests, there is no way to bootstrap this in NetBeans. You have to create the directory "test/unit" in the project, and restart NB, and then you have unit test support. We should make this achievable as part of the UI, rather than requiring a secret incantation that only the initiated know about. I have experienced this with NB modules that are part of the NB build. I don't know if this is also an issue for standalone modules.
the same for functional tests and you have to create "test/unit/src" directory, just "test/unit" not enough
I'm for to create some general support for this, recently i had to create some folder structure in my maven project in order to make Test packages node appear.
Jesse, Richard, possible to fix this?
New module wizard creates test/unit/src folder automatically. It may be missing, e.g. as a result of version control pruning empty folders, and in such case JUnit obviously cannot create the test - the test root folder does not exist. But apisupport does not know when the test root folder is really needed (so that it can create it on demand), JUnit support asks UnitTestForSourceQueryImpl#findUnitTests quite often, e.g. when popup menu shows up. Possible solutions are: 1) Let apisupport project create test root folder (if it is missing) anytime it is asked for it via UnitTestForSourceQueryImpl#findUnitTests. Behaves strangely, e.g. test root folder is created when popup menu shows up. 2) Consider apisupport project without test root folder to be corrupted and create folder automatically upon opening. The same with QA functional tests folder? 3) Extend the API to allow creation of test folders on demand. Any other ideas? #1 behaves strangely and #3 is IMO an overkill, I'll implement #2 if nobody objects.
#1 and #2 are out of the question IMHO. Probably needs #3, a new API - something like ClassPathModifier but for source roots. From what I can see, this complaint applies also to j2seproject's. (In that case you are able to add a test root from the Properties dialog, but the New JUnit Test wizard does not offer to add a source root for you.)
#3 would solve this for Maven too. For Maven is dialog with message misleading, testroots cannot be customized in properties.
Ok, I'll try to propose the new API.
please note that the given API would be generally useful for test creation (via the junit module's UI) as well.
*** Issue 157094 has been marked as a duplicate of this issue. ***
*** Issue 165109 has been marked as a duplicate of this issue. ***
Created attachment 83196 [details] api change
Created attachment 83197 [details] usage in apisupport projects
Created attachment 83198 [details] usage in j2se projects
Uses SourceGroupModifierImplementation introduced in issue #102711, generic Ant-based projects implementation can take source roots (which needn't to exist physically) previously added into o.n.spi.project.support.ant.SourcesHelper and create them on demand in SGMI.createSourceGroup(type, hint). This needs changes in SourcesHelper: 1) Add variants of addPrincipalSourceRoot and addTypedSourceRoot methods with "hint" parameter, hint is then used in SGMI impl. 2) Add method createSourceGroupModifierImplementation(Sources), which creates SGMI impl that can be added to project lookup. Sources previously created by SourcesHelper.createSources() must be passed as argument so that SGMI can access source roots. Please review the api change, usages in apisupport project and J2SE project are included as well.
Miloš should be main reviewer, as developer of issue #102711. [JG01] helper.resolveFile(path) should already be normalized, no need to call .normalize() on the result AFAIK. [JG02] Any changes should be done to all Ant-based project types, not just j2seproject. Use java.api.common as needed for factoring out common bits. This new code also needs test coverage. [JG03] Complex Javadoc should not be duplicated. Keep all details in just one place and refer to it (@link) from other overloads as needed. Since there are now so many parameters to SH add* methods, better would probably be to introduce a SourceRootConfiguration builder: sourcesHelper.config("${test.unit.src.dir}").type("java").displayName("Unit Tests").hint("test").add(); [JG04] Make sure you add @since, update spec versions (incl. usages from client modules), introduce apichanges.xml entry, etc. [JG05] Is there any actual use case for addPrincipalSourceRoot with a hint? I don't think so; this would be used only with typed source roots AFAIK. Harmless is using builder pattern as in JG03, noisy otherwise. [JG06] SourceGroupModifierImpl could be static, right? Or is it required that the same SourcesHelper was used to call createSources as was used to call createSourceGroupModifierImplementation? Maybe just have the returned Sources object also implement SourceGroupModifierImplementation (and document this). Would not affect existing usages unless they actually declared hints on anything, right? Alternately, have createSourceGroupModifierImplementation take no args. For sources.maybeFireChange(), just have SourcesHelper keep a WeakSet<SourcesImpl> of what it has created in createSources. This might anyway be easier to use; some modules call createSources repeatedly (to create a proxy wrapper for it), whereas it might be useful to just call createSourceGroupModifierImplementation once and put it directly into lookup, resting assured that it would correctly fire changes from any SourcesImpl. Best would be to ensure that SourcesImpl is smart enough to fire its own changes when the folder is created for any reason, not just that SourceGroupModifierImpl happened to be used. FileUtil.addFileChangeListener should ensure this, so long as you create the folder using org.openide.filesystems.* calls - so do not use File.mkdirs (which will anyway log a warning when you call FileUtil.toFileObject). [JG07] HINT_NONE could perhaps simply be replaced by null.
JG01: You mean normalizing URI in UnitTestFSQI? Ok then. JG02: I wrote tests later and forgot to put here, attaching patch (143663-api-2.diff). Regarding implementing for all project types - is that the usual approach? Even when I manage to do it for all kinds of j2ee projects, bpel, mobility, etc. I find it quite ineffective for me to browse through all the code I should not work at instead of working on areas where I'm supposed to work. I can of course file enhancements for other project types. There's not much to factor out to java.api.common, it's just about getting all the notifications right, which are done in every project type a bit differently. JG03: ad Javadoc: ok, will do. Regarding SourceRootConfiguration builder: thought about it, does it mean I should deprecate "old" methods with parameters? Otherwise there will be 2 different api-s doing almost the same thing, which seems confusing to me. JG04: yep, already included in newer patch JG05: no use case, I added it to make api symetrical. Will go away with JG03. JG06: ad SGMI static: it cannot be static, it uses principal/typedSourceRoots stored in SH when creating the group. ad Sources implementing SGMI: I even tried it, but some clients need to implement SGMI themselves and delegate to impl. from SH. Which impl is then found in project lookup is then AFAIK dependant on the order of addition, which seems fragile to me. But your idea with WeakSet of all created Sources solves this and simplifies the API, thanks for the tip. ad notifications: yep, I then found out that FileUtil.createFolder fires notifications properly and simplifies use in clients. Already in newer patch. JG07: ok
Created attachment 83437 [details] Newer patch with API + J2SE impl, tests, apichanges
JG02 - yes please ensure all project types are updated. If you cannot do it yourself for a project type, file an issue for the maintainers. JG03 - if introducing a builder then yes it would be good to deprecate the old methods. JG06 - new patch still seems to be using sources.maybeFireChanges, rather than WeakSet<SourcesImpl> or relying on file change notifications... do you still plan to change this, so that createSourceGroupModifierImplementation would not need to take args?
ad JG02: ok, will file issues for other project types ad JG01, JG03, JG06: attaching complete patch 143633-v2.diff, previous one contained just changes I made in parallel before the review.
ad JG02: as for the rest of the project types it seems that the only affected ones that directly support creating JUnit tests are J2EE projects (app-client, ejb and web), so I fixed them as well. Jesse, thanks for the review, integrating into core-main #d19bfd6c52d4
Integrated into 'main-golden', will be available in build *200906190201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/d19bfd6c52d4 User: Richard Michalsky <rmichalsky@netbeans.org> Log: #143633: on-demand creation of test source roots for Ant-based projects
Integrated into 'main-golden', will be available in build *200906200201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/fc6cb7335c64 User: Richard Michalsky <rmichalsky@netbeans.org> Log: cleanup after #143633: javadoc, apichanges, parameters checking
Verified in 200907070200
The fix has been ported into the release67_fixes repository. http://hg.netbeans.org/release67_fixes/rev/7f87dfd4d47b
The backport was not quite correct: while the spec version of project.ant was correctly changed to 1.31.2, and module dependencies were updated correspondingly, the occurrences of 1.33 in apichanges.xml and the two new @since tags in SourcesHelper.java need to also be changed to 1.31.2. We should also remember to publish updated 6.7 Javadoc after patches are released, for cases where API changes were backported.
Jesse, thanks for catching it. Richard will fix these in release67_fixes repo.
http://hg.netbeans.org/release67_fixes/rev/eb17dbb56d3e
could someone please explain me how I can add qa-functional test if test/qa-functional folder doesn't exists?
> could someone please explain me how I can add qa-functional test if test/qa-functional folder doesn't exists? As before, create test/qa-functional/src folder in the project root and add a test there. This fix doesn't apply to qa-functional tests as there is no wizard for creating them.
verified in 6.7.1