Skip to content

Proposal: Improve portal dependent components (e.g. QSelect , QButtonGroup etc) testing experience #371

Open
@thevladisss

Description

@thevladisss

Issue:
Testing QSelect and other portal dependent components is heavy and time consuming. By portal dependent I mean the components that actually trigger portal based components to appear e.g. Menu, Dialog.

The biggest problem is that portal based components like Menu do not know know who called them and this causes the issue when testing components specifically or during E2E tests. Couple of different menu or dialogs can be open at the same time and withinSelectMenu command might bot be able to handle this scenario.

Solution:
When QSelect triggers mount for QMenu or QDialog, a specific attribute that should be put onto the instantiated portal based component to be able to refer to the caller. In this case custom commands like "withinSelectMenu" can become chainable or can accept a selector be able to query the menu trigerred by selector

Cypress.Commands.add('withinSelectElement', { prevSubject: 'optional' }, (subject, callback, selector) => {
	if (subject && !selector) {
  	/**
    	Assume all menus created by use of QSelect have data-caller="1"
    */
  	selector = ".q-menu" + "[data-caller=" + subject.attr('id') + "]"
  }
  
    	cy.root().closest('html').get(selector).within(callback)
})

cy.dataCy('dropdown-persons').withinSelectElement(() => {})


There is a way however to circumvent it now, it is by passing selector to "popupContentClass" in QSelect element and explicitly querying this element, however I beleive that is not the best solution

IMPORTANT NOTE

This requires updating the QSelect element, and is not only matter of updating this package.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions