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
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
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
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]
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
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
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
[JG04] Make sure you add @since, update spec versions (incl. usages from client modules), introduce apichanges.xml
[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
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.
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)
User: Richard Michalsky <firstname.lastname@example.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)
User: Richard Michalsky <email@example.com>
Log: cleanup after #143633: javadoc, apichanges, parameters checking
Verified in 200907070200
The fix has been ported into the release67_fixes repository.
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.
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