Testing Tips"
m (→ID and UUID) |
|||
| Line 10: | Line 10: | ||
==Approach 1: Use Widget's ID== | ==Approach 1: Use Widget's ID== | ||
| − | , | + | With [[ZK Developer's Reference/Architecture Overview|Server+client architecture]], ZK maintains an ''identical'' world at the client. If your test tool is able to access JavaScript at the client, your test code could depend on the widget's ID and widget's parent-child-relationship as your application code depends on the component's ID and component's parent-child-relationship. They are ''identical'', except one is JavaScript and called <javadoc directory="jsdoc">zk.Widget</javadoc>, while the other is Java and called <javadoc type="interface">org.zkoss.zk.ui.Component</javadoc>. |
| − | + | ||
| − | + | This is 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 <javadoc directory="jsdoc">_global_.jq</javadoc> and/or <javadoc directory="jsdoc" method="$(zk.Object, _global_.Map)">zk.Widget</javadoc> (they are all client-side API). <javadoc directory="jsdoc">_global_.jq</javadoc> allows your test code to access the components directly, so the test code could depend on widget's ID (<javadoc directory="jsdoc" method="id">zk.Widget</javadoc>) and the widget tree (<javadoc directory="jsdoc" method="firstChild">zk.Widget</javadoc>, <javadoc directory="jsdoc" method="nextSibling">zk.Widget</javadoc> and so on). | |
| + | |||
| + | <source lang="javascript"> | ||
| + | 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 | ||
| + | </source> | ||
| + | |||
| + | With this approach, you still can verify the DOM structure if you want, since it can be retrieved from widget's <javadoc directory="jsdoc" method="$n()">zk.Widget</javadoc>. | ||
| + | |||
| + | [http://code.google.com/p/zk-ztl/ ZTL] is a typical example that takes this approach. For more information, please refer to the [[ZK Developer's Reference/Test/ZTL|ZTL section]]. | ||
==Approach 2: Implement ID Generate== | ==Approach 2: Implement ID Generate== | ||
Revision as of 04:38, 29 November 2010
ID and UUID
By default, the desktop's ID and component's UUID are randomized, such that the chance to pick up a wrong component is minimized if the sever is restarted. Since component's UUID will become DOM element's ID at the browser, it means the DOM element's IDs will change from one test run to another.
If your test code runs at the server (such 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
With Server+client architecture, ZK maintains an identical world at the client. If your test tool is able to access JavaScript at the client, your test code could depend on the widget's ID and widget's parent-child-relationship as your application code depends on the component's ID and component's parent-child-relationship. They are identical, except one is JavaScript and called Widget, while the other is Java and called Component.
This is 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().
ZTL is a typical example that takes this approach. For more information, please refer to the ZTL section.
Approach 2: Implement ID Generate
Version History
| Version | Date | Content |
|---|---|---|