Testing Tips"
From Documentation
m (Created page with '{{ZKDevelopersReferencePageHeader}} =Version History= {{LastUpdated}} {| border='1px' | width="100%" ! Version !! Date !! Content |- | | | |} {{ZKDeveloper…') |
|||
| Line 1: | Line 1: | ||
{{ZKDevelopersReferencePageHeader}} | {{ZKDevelopersReferencePageHeader}} | ||
| + | |||
| + | =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. | ||
| + | |||
| + | There are generally two solutions for it. | ||
| + | |||
| + | # 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 | ||
| + | |||
| + | =Approach 1: Use Widget's ID= | ||
| + | , 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). | ||
| + | **This is the suggested approach since it is much easier to test in the component level (aka., the widget level, <javadoc directory="jsdoc">zk.Widget</javadoc>). | ||
| + | ** For example, [http://code.google.com/p/zk-ztl/ 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 <javadoc directory="jsdoc" method="$n()">zk.Widget</javadoc>. | ||
| + | |||
| + | =Approach 2: Implement ID Generate= | ||
=Version History= | =Version History= | ||
Revision as of 04:16, 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.
There are generally two solutions for it.
- 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 |
|---|---|---|