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.

Bug 197066 - Functional tests ignore application branding
Summary: Functional tests ignore application branding
Alias: None
Product: apisupport
Classification: Unclassified
Component: Harness (show other bugs)
Version: 7.0.1
Hardware: All All
: P3 normal (vote)
Assignee: Jesse Glick
Depends on: 197065 212019
Blocks: 205653
  Show dependency tree
Reported: 2011-03-24 20:55 UTC by tomwheeler
Modified: 2012-05-03 18:47 UTC (History)
1 user (show)

See Also:
Exception Reporter:

minimal suite which can be used to reproduce the problem (26.28 KB, application/x-zip-compressed)
2011-03-24 20:55 UTC, tomwheeler
Update to the TestSayHelloMenu testcase from the attached suite. (1.13 KB, text/x-java-source)
2011-03-28 18:34 UTC, tomwheeler
Build scripts provide branding.token property to NbModuleSuite (6.28 KB, patch)
2011-12-01 14:16 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description tomwheeler 2011-03-24 20:55:05 UTC
Created attachment 107262 [details]
minimal suite which can be used to reproduce the problem

While working on functional tests, I found that the application branding is ignored for the application under test.  I am able to reproduce this using NetBeans 7.0 (built today from release branch) and have attached a minimal suite which demonstrates the problem.

Following these steps should illustrate the issue:

1.  Unpack the suite and open it using NB IDE 7.0

2.  Run the application (suite -> run)

3.  Note custom branding (splash screen, frame title, etc.)

4.  Close the application

5.  Open com.tomwheeler.appstuff.TestSayHelloMenu class in the "Functional Test Packages" folder of the module.

6.  Press Ctrl+F6 to execute the test

7.  Note that the branding observed while running the suite (e.g. customized frame title) is not observed when the application is launched as a functional test.  

In my view, the application should look and behave exactly the same when being tested or being run normally.  Any deviation from that renders test results suspect.

I do not know of a workaround, though I suppose once #197065 is implemented, an application may be able to specify --branding as a command line parameter.  But I think even that is just a workaround, since the application ought to have the correct branding when launched from a functional test without having to do anything special.
Comment 1 tomwheeler 2011-03-28 18:34:48 UTC
Created attachment 107346 [details]
Update to the TestSayHelloMenu testcase from the attached suite.

The TestSayHelloMenu from the attached suite should be replaced with this one.  It demonstrates that, once the patch for #197065 has been applied, you can use the "addStartupArgument" method to pass a --branding startup argument to work around the issue I've reported here.
Comment 2 Jaroslav Tulach 2011-05-14 15:25:29 UTC
I guess this bug is now resolved as well.

*** This bug has been marked as a duplicate of bug 197065 ***
Comment 3 tomwheeler 2011-05-16 15:53:50 UTC
I guess I did not clearly describe what the problem is.  I filed this issue because I think that no special configuration should be necessary to make functional tests look and behave the same as when running the application normally.  

In other words, when you invoke "ant test" on a project with functional tests, it should automatically use the same branding as when you invoke the "ant run" target.  Previously there was no way to get the right branding -- even manually -- though the implementation of #197065 allowed for a workaround by specifying an explicit '--branding' option (thereby duplicating the branding.token property in the suite's file).  

I don't have any suggestions on how to implement that, so if you still want to close this issue, I will not complain.  I just want to make sure you understand the problem I was describing.
Comment 4 Jesse Glick 2011-12-01 14:13:10 UTC
The test infrastructure cannot and does not have any idea what branding might be used by some application that happens to include this module. Any defaulting of the branding token would have to be done with the cooperation of the build harness; NbModuleSuite could at best set a default branding based on some system property given to it.

Ant-based apps could perhaps define some test-qa-functional-sys-prop.* in test-lib-init. This would be tricky since ${branding.token} is currently defined in, which is inaccessible to a module's build; it would have to be moved to, perhaps reversing the order of defaulting w.r.t. ${}, with corresponding changes in not just the project generator, but also the branding support which writes these keys, and even some sort of upgrade-on-open for existing suites.

In the case of Maven builds, functional tests are expected to reside only in the nbm-application project (since modules have no reference to the containing app and indeed may be contained in any number of apps). Passing branding as a system property via Surefire would be possible by configuring the application/pom.xml, which could be done by default in the archetype. More generally, NbModuleSuite could simply read ${all.clusters}/etc/*.conf#default_options if it exists, which would set the branding token in the case of a Maven app.
Comment 5 Jaroslav Tulach 2011-12-01 14:16:54 UTC
Created attachment 113705 [details]
Build scripts provide branding.token property to NbModuleSuite
Comment 6 Jesse Glick 2011-12-01 15:22:25 UTC
Obviously you did not mean to include o.eclipse.equinox.common in this patch.

<loadproperties> should not use prefix="test-unit-sys-prop." as this could accidentally pass unrelated and unwanted properties to unit tests.

-1 on reading ${suite.dir}/nbproject/ in this way. is intended for the private use of the suite's build script. The design is that all properties needed to be shared between the suite build and individual module builds should be in (which is loaded in init by both kinds of builds); in either the suite or a module is permitted to define additional project-specific properties which can interpolate definitions from
Comment 7 Jaroslav Tulach 2011-12-01 17:04:47 UTC
Partially fixed for 7.1 in 1d68ed5a153d, rest is up to Jesse.
Comment 8 Jesse Glick 2011-12-01 18:11:39 UTC
Using in Maven archetype as of revision 15448 (1.11-SNAPSHOT).
Comment 9 Quality Engineering 2011-12-04 11:59:00 UTC
Integrated into 'main-golden'
User: Jaroslav Tulach <>
Log: Partial fix for #197066: If 'branding.token' is specified, use it as a branding for the test
Comment 10 Jesse Glick 2012-04-25 22:16:30 UTC
#205653 implemented branding.token=nb for modules.

Will fix harness for external modules to consider ${branding.token} from, and will make new application wizard put it there.

Since it is not there for current apps, will make it possible to upgrade an existing app by opening the Properties dialog, going to the Application panel, and clicking OK (no need to make any actual changes).
Comment 11 Jesse Glick 2012-04-25 22:19:25 UTC
core-main #6684d3af6704
Comment 12 Quality Engineering 2012-04-26 10:29:13 UTC
Integrated into 'main-golden', will be available in build *201204260400* on (upload may still be in progress)
User: Jesse Glick <>
Log: #197066: functional tests ignore application branding.
Fixing for Ant-based suites.