Any intention to support query-extensions or similar API?

[Mehdi-Hp]

I came across query-extensions and I think this is a step up in front-end testing.
The API I'm interested the most is filter: "role", in which, you can select different elements based on their representation on accessibility tree. I believe this leads us to have more a11y friendly code, and broken-free tests.

Rough idea:

const wrapper = mount(BaseButton);

const ui = {
    button: { filter: 'role', params: ['button'] },
    loadingSpinner: { filter: 'role', params: ['alert'] }
}
wrapper.query(ui.button).trigger('click');

expect(
    wrapper.query(ui.loadingSpinner).isVisible()
).toBe(true);

[standbyoneself]

Do you mean querying elements by ARIA roles better than querying by selectors? It seems to me it has many disadvantages.

1) Firstly, you need to remember bunch of roles. 2) Secondly, there are many elements that are often used but have not a corresponding role e.g. p, label, input (type="password"), div and explicitly assigning roles is not recommended by W3C (https://www.w3.org/TR/html-aria/#docconformance). 3) Thirdly, <input type="text" /> and <textarea />, <input type="submit" /> and <button /> have a same role, how to properly target these? Filter by role and by text content? What if you decide to change text of a button element? You also need to change your filter.

Broken-free tests? Are you serious? If you add the empty alt attribute to the img, its role becomes "presentation" instead of "img". Similar case with select.

In my opinion it is all testing-library specific and has very doubtful approach. If you use data attributes like data-testid="password-input", you can easily target elements both by Vue Test Utils, Enzyme, Cypress and it will be consistent.

[lmiller1990]

I am all for accessible components. That said, I don't think we need this in Vue Test Utils - it seems like these would already work out of the box with @testing-library/vue: https://github.com/testing-library/vue-testing-library (which is using Test Utils internally). Would that work for your use case?

Alternatively, you could build this yourself pretty easily as a plugin: https://next.vue-test-utils.vuejs.org/guide/extending-vtu/plugins.html.

Something like:

const queryPlugin = (wrapper) => {
  return {
    query: (queryObj) => {
      return wrapper.get(/* your custom query logic here */)
    }
  }
}

If you'd like to write a plugin for this, I could contribute and help out. We could even link to it from the docs. I'd like to see a more vibrant plugin ecosystem, as opposed to increasing the surface area of this library. It's already quite a lot to maintain and the primary focus at this point in time is maintainability and reliability of existing features, as opposed to features.

[lmiller1990]

Happy to reopen or continue discussion if the above answer doesn't solve the problem. I'll close this for now, just to keep issues under control.

Closed doesn't mean the discussion is over - just that there is no work to be done right now.