Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 143633 - No way to easily set up tests for a module
No way to easily set up tests for a module
Status: VERIFIED FIXED
Product: apisupport
Classification: Unclassified
Component: Project
6.x
All All
: P3 with 1 vote (vote)
: 6.x
Assigned To: rmichalsky
issues@apisupport
67patch1-verified
: API, API_REVIEW_FAST
: 157094 165109 (view as bug list)
Depends on: 102711
Blocks: 89008
  Show dependency treegraph
 
Reported: 2008-08-12 16:40 UTC by David Vancouvering
Modified: 2009-07-21 12:34 UTC (History)
10 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
api change (18.31 KB, text/plain)
2009-06-04 11:29 UTC, rmichalsky
Details
usage in apisupport projects (6.55 KB, text/plain)
2009-06-04 11:30 UTC, rmichalsky
Details
usage in j2se projects (11.11 KB, text/plain)
2009-06-04 11:31 UTC, rmichalsky
Details
Newer patch with API + J2SE impl, tests, apichanges (31.79 KB, patch)
2009-06-11 10:37 UTC, rmichalsky
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Vancouvering 2008-08-12 16:40:01 UTC
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.
Comment 1 Ivan Sidorkin 2008-08-12 17:12:59 UTC
the same for functional tests
and you have to create "test/unit/src" directory, just "test/unit" not enough
Comment 2 Tomas Danek 2008-08-12 17:41:38 UTC
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.
Comment 3 Antonin Nebuzelsky 2008-08-15 12:59:14 UTC
Jesse, Richard, possible to fix this?
Comment 4 rmichalsky 2008-08-18 16:09:44 UTC
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.
Comment 5 Jesse Glick 2008-08-18 18:19:36 UTC
#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.)
Comment 6 Tomas Danek 2008-08-18 18:50:26 UTC
#3 would solve this for Maven too. For Maven is dialog with message misleading, testroots cannot be customized in
properties.
Comment 7 rmichalsky 2008-08-29 10:16:35 UTC
Ok, I'll try to propose the new API.
Comment 8 Milos Kleint 2008-10-07 09:12:44 UTC
please note that the given API would be generally useful for test creation (via the junit module's UI) as well.
Comment 9 rmichalsky 2009-04-09 15:04:41 UTC
*** Issue 157094 has been marked as a duplicate of this issue. ***
Comment 10 rmichalsky 2009-05-14 09:24:49 UTC
*** Issue 165109 has been marked as a duplicate of this issue. ***
Comment 11 rmichalsky 2009-06-04 11:29:49 UTC
Created attachment 83196 [details]
api change
Comment 12 rmichalsky 2009-06-04 11:30:46 UTC
Created attachment 83197 [details]
usage in apisupport projects
Comment 13 rmichalsky 2009-06-04 11:31:22 UTC
Created attachment 83198 [details]
usage in j2se projects
Comment 14 rmichalsky 2009-06-04 11:35:06 UTC
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.
Comment 15 Jesse Glick 2009-06-09 18:01:29 UTC
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.
Comment 16 rmichalsky 2009-06-11 10:35:36 UTC
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
Comment 17 rmichalsky 2009-06-11 10:37:03 UTC
Created attachment 83437 [details]
Newer patch with API + J2SE impl, tests, apichanges
Comment 18 Jesse Glick 2009-06-16 01:05:47 UTC
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?
Comment 19 rmichalsky 2009-06-16 14:09:11 UTC
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.
Comment 20 rmichalsky 2009-06-18 12:58:14 UTC
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
Comment 21 Quality Engineering 2009-06-19 07:47:09 UTC
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
Comment 22 Quality Engineering 2009-06-20 08:06:41 UTC
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
Comment 23 martin_zmrhal 2009-07-07 12:27:45 UTC
Verified in 200907070200
Comment 24 pgebauer 2009-07-08 16:20:27 UTC
The fix has been ported into the release67_fixes repository.
http://hg.netbeans.org/release67_fixes/rev/7f87dfd4d47b
Comment 25 Jesse Glick 2009-07-08 17:55:09 UTC
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.
Comment 26 Antonin Nebuzelsky 2009-07-15 15:55:28 UTC
Jesse, thanks for catching it. Richard will fix these in release67_fixes repo.
Comment 28 Ivan Sidorkin 2009-07-21 10:41:39 UTC
could someone please explain me how I can add qa-functional test if test/qa-functional folder doesn't exists?
Comment 29 rmichalsky 2009-07-21 10:51:06 UTC
> 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.
Comment 30 Ivan Sidorkin 2009-07-21 12:34:41 UTC
verified in 6.7.1


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo