ID and UUID
By default, the desktop's ID and component's UUID are randomized for preventing Cross-Site Request Forgery (CSRF) and allowing multiple desktops coexists in the same web page (such as Portlet). However, it also means the DOM element's IDs will change from one test run to another, since component's UUID will become DOM element's ID at the browser, .
If your test code runs at the server (such ZATS and JUnit), it is not an issue at all (since DOM elements are available at the client only). However, if your test tool runs at the browser, you have to resolve it with one of the following solutions:
- Not to depend on DOM element's ID. Rather, use component's ID and/or component's parent-child-sibling relationship.
- Implement IdGenerator to generate UUID in a predictable and repeatable way
Approach 1: Use Widget's ID
This is a suggested approach, since it is much easier to test an application in the same abstract level -- the component level, aka., the widget level (rather than DOM level).
To retrieve widgets at the client, you could use jq and/or Widget.$(Object, Map) (they are all client-side API). jq allows your test code to access the components directly, so the test code could depend on widget's ID (Widget.id) and the widget tree (Widget.firstChild, Widget.nextSibling and so on).
jq('@window[border="normal"]') //returns a list of window whose border is normal jq('$x'); //returns the widget whose ID is x jq('$x $y'); //returns the widget whose ID is y and it is in an ID space owned by x
With this approach, you still can verify the DOM structure if you want, since it can be retrieved from widget's Widget.$n().
Approach 2: Implement ID Generator
To implement a custom ID generator, you have to do the following:
- Implement a Java class that implements IdGenerator.
- Specify the Java class in WEB-INF/zk.xml with the id-generator-class element. For example,
<system-config> <id-generator-class>my.IdGenerator</id-generator-class> </system-config>
Since ZK 7.0.0, we provide a static ID generator implementation for testing, to use StaticIdGenerator, simply add it to zk.xml.
<system-config> <id-generator-class>org.zkoss.zk.ui.impl.StaticIdGenerator</id-generator-class> </system-config>
Different Configuration for Different Environment
If you prefer to have a different configuration for the testing environment (such as specifying ID generator for testing), you could put the configuration in a separated file, say, WEB-INF/config/zk-testing.xml with the following content.
<zk> <system-config> <id-generator-class>my.IdGenerator</id-generator-class> </system-config> </zk>
Then, you could you could specify -Dorg.zkoss.zk.config.path=/WEB-INF/config/zk-testing.xml as one of the arguments when starting the Web server.
Disabled UUID recycle
If you want to generate uuid with some conditional , you might also want to disable UUID recycle. ( It will reuse all the uuids from removed components.) You could set the properties org.zkoss.zk.ui.uuidRecycle.disabled in zk.xml .
Last Update : 2013/10/15
|Copyright © Potix Corporation. This article is licensed under GNU Free Documentation License.|