Testing Tips"
From Documentation
| Line 4: | Line 4: | ||
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. | 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 tool runs at the browser, you have to resolve it with one of the following solutions. However, 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). | |
# Not to depend on DOM element's ID. Rather, use component's ID and/or component's parent-child-sibling relationship. | # Not to depend on DOM element's ID. Rather, use component's ID and/or component's parent-child-sibling relationship. | ||
# Implement <javadoc type="interface">org.zkoss.zk.ui.sys.IdGenerator</javadoc> to generate UUID in a predictable and repeatable way | # Implement <javadoc type="interface">org.zkoss.zk.ui.sys.IdGenerator</javadoc> to generate UUID in a predictable and repeatable way | ||
| − | =Approach 1: Use Widget's ID= | + | ==Approach 1: Use Widget's ID== |
, i.e., use <javadoc directory="jsdoc">_global_.jq</javadoc> (client-side API) instead | , i.e., use <javadoc directory="jsdoc">_global_.jq</javadoc> (client-side API) instead | ||
**<javadoc directory="jsdoc">_global_.jq</javadoc> allows your test code to access the components directly, so the test code could depend on component's ID (<javadoc type="interface" method="getId()">org.zkoss.zk.ui.Component</javadoc>) and the component tree (<javadoc type="interface" method="getNextSibling()">org.zkoss.zk.ui.Component</javadoc>, <javadoc type="interface" method="getFirstChild()">org.zkoss.zk.ui.Component</javadoc> and so on). | **<javadoc directory="jsdoc">_global_.jq</javadoc> allows your test code to access the components directly, so the test code could depend on component's ID (<javadoc type="interface" method="getId()">org.zkoss.zk.ui.Component</javadoc>) and the component tree (<javadoc type="interface" method="getNextSibling()">org.zkoss.zk.ui.Component</javadoc>, <javadoc type="interface" method="getFirstChild()">org.zkoss.zk.ui.Component</javadoc> and so on). | ||
| Line 16: | Line 16: | ||
** 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>. | ** 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>. | ||
| − | =Approach 2: Implement ID Generate= | + | ==Approach 2: Implement ID Generate== |
=Version History= | =Version History= | ||
Revision as of 04:20, 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 tool runs at the browser, you have to resolve it with one of the following solutions. However, 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).
- 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
, i.e., use jq (client-side API) instead
- jq allows your test code to access the components directly, so the test code could depend on component's ID (Component.getId()) and the component tree (Component.getNextSibling(), Component.getFirstChild() and so on).
- This is the suggested approach since it is much easier to test in the component level (aka., the widget level, Widget).
- For example, ZTL takes this approach to make the test code independent of DOM structures.
- 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 Generate
Version History
| Version | Date | Content |
|---|---|---|