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.
Summary: | Functional tests ignore application branding | ||
---|---|---|---|
Product: | apisupport | Reporter: | tomwheeler <tomwheeler> |
Component: | Harness | Assignee: | Jesse Glick <jglick> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jglick |
Priority: | P3 | ||
Version: | 7.0.1 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 197065, 212019 | ||
Bug Blocks: | 205653 | ||
Attachments: |
minimal suite which can be used to reproduce the problem
Update to the TestSayHelloMenu testcase from the attached suite. Build scripts provide branding.token property to NbModuleSuite |
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.
I guess this bug is now resolved as well. *** This bug has been marked as a duplicate of bug 197065 *** 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 project.properties 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. 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 project.properties, which is inaccessible to a module's build; it would have to be moved to platform.properties, perhaps reversing the order of defaulting w.r.t. ${app.name}, 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. Created attachment 113705 [details]
Build scripts provide branding.token property to NbModuleSuite
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/project.properties in this way. project.properties 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 platform.properties (which is loaded in init by both kinds of builds); project.properties in either the suite or a module is permitted to define additional project-specific properties which can interpolate definitions from platform.properties. Partially fixed for 7.1 in 1d68ed5a153d, rest is up to Jesse. Using in Maven archetype as of revision 15448 (1.11-SNAPSHOT). Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/1d68ed5a153d User: Jaroslav Tulach <jtulach@netbeans.org> Log: Partial fix for #197066: If 'branding.token' is specified, use it as a branding for the test #205653 implemented branding.token=nb for nb.org modules. Will fix harness for external modules to consider ${branding.token} from platform.properties, 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). core-main #6684d3af6704 Integrated into 'main-golden', will be available in build *201204260400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/6684d3af6704 User: Jesse Glick <jglick@netbeans.org> Log: #197066: functional tests ignore application branding. Fixing for Ant-based suites. |
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.