@axinom/mosaic-e2e-ui-selectors

@axinom/mosaic-e2e-ui-selectors

About the Package

This package is part of the Axinom Mosaic development platform. More information can be found at https://portal.axinom.com/mosaic.

This library models components in the Mosaic UI library, @axinom/mosaic-ui for use in Playwright tests. Exported class UiWorkflowsModel provides a model to navigate the DOM tree and to perform operations and assertions with Playwright.

This library should be used to model customized services. It should be used in concert with @axinom/mosaic-page-models which models the Mosaic management system including the shell UI and managed services.

License

This package can be licensed under the Axinom Products Licensing Agreement or evaluated under the Axinom Products Evaluation Agreement.
No part of Axinom's software may be copied, modified, propagated, or distributed except in accordance with the terms contained in the Axinom Products Licensing Agreement and Axinom Products Evaluation Agreement.

Library Conventions

Many conventions should be obvious from reading the code. Still, for clarity there are some, maybe less obvious, conventions described here. The library is designed to leverage the capabilities of intellisense to guide a test author and to minimise the need to refer to documentation and source. Conventions are designed to foster intuition in the user, and to improve readability of tests.

• All models are extended from the ComponentModel class.
• If the desired functionality of an element can be achieved with a Locator then return a Locator rather than modelling behavior through additional methods and properties.

Exposing Locators empowers the test author, e.g. by enabling expressive expect statements which wait gracefully. There are exceptions to the rule, e.g. where an element is a generic container that could contain any other UI components, a ComponentModel can be more flexible as it has the getChild method.

• Classes extending ComponentModel should mirror components defined in the UI library where possible. The naming and structure should be aligned.
• Method parameters should be simple. Preferably just strings and numbers with sufficient doc comments to guide the user.

Enums and typed objects as parameters are good for enforcing type safety but they require an additional level of introspection when authoring tests. If a test fails due to a string typo its easy to fix. If there is a limited set of options which can be codified, consider a method for each so that intellisense will list them alongside other methods and properties (e.g. see UntypedFormField).