Testing Tips
From Documentation
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 |
|---|---|---|