Open Slooti opened 5 years ago
Perhaps a solution could be to add a "semantic" tag to each component, for example to click a select:
$('[data-vuetify-ref=v-select-open]').click()
in this way you avoid using the id (components in read and write normally use different elements). Obviously you can have more v-select in the same page, in that case you can access it by positional inde
How other frameworks handle it?
Any progress on this, so far?
I encountered this issue recently when using v-list-group component. So component initialization would look like this (only important code):
`<v-list-group v-for="(item, index) in navigationComputed" :key="index" :class="formatNavigationTestingClass()"
`
Method formatNavigationTestingClass() will just return string "testing-class". So the end result of this would be as shown in this screenshot:
I managed to achieve something by extending v-list-group component in VUE.js. So I would use extended component which would accept testingClass property. The extended component also has override of genHeader() method - https://github.com/vuetifyjs/vuetify/blob/master/packages/vuetify/src/components/VList/VListGroup.ts#L137
So in the extended component testingClass is added along with the other classes in genHeader() method. So the final result is this:
Class is now being added to the correct div element. Although the final result is satisfactory, the method used to achieve this is a bit hackish. There are 2 major problems with this approach, so it shouldn't be considered as a long term solution.
With future Vuetify upgrades, component code could be changed and extensions will cease to work.
This is just the example of extension of v-list-group component. So, in order to achieve complete automated testing of the application, a lot of other components should be extended as well in a similar manner.
All in all, this is not a long term solution. Are there any plans to tackle this? Has anyone made any progress with custom solutions?
Need a solution as well for selenium end to end testing
Just an update, this issue is currently in progress and will be resolved as part of a patch release under v2.3.
Just an update, this issue is currently in progress and will be resolved as part of a patch release under v2.3.
Thanks for your work on this. Is there any ETA on this issue?
Just an update, this issue is currently in progress and will be resolved as part of a patch release under v2.3.
Has this been released?
most elements work fine added "id" property.
v-autocomplete is one that does not play nicely.
my solution with puppeteer/jest
const element = await page.waitForSelector('#Timezone');
await element.click();
await element.type('Asia/Taipei');
await element.press('Enter');
If someone might find it useful.
Am I correct in assuming this was bumped to v3 and will never be implemented in v2.x?
Am I correct in assuming this was bumped to v3 and will never be implemented in v2.x?
That is correct. Unfortunately we do not have the bandwidth to backport any changes that would resolve this.
I'm interested in this as well. I might be able to contribute something. Has there been any discussion around how to implement this? Easiest seems to be to sprinkle some data-vuetify
attributes on elements where it makes sense. For example, this is how a part of the footer of a <v-data-table>
could look like:
<div class="v-data-table-footer" data-vuetify="footer">
<div class="v-data-table-footer__pagination" data-vuetify="pagination">
<button type="button" aria-label="First page" data-vuetify="first"></button>
<button type="button" aria-label="Previous page" data-vuetify="previous"></button>
<button type="button" aria-label="Next page" data-vuetify="next"></button>
<button type="button" aria-label="Last page" data-vuetify="last"></button>
</div>
</div>
I've added data-vuetify
attributes to the footer, the pagination section and to each button in the pagination section. The idea is to have fairly generic names and drill down using selectors before getting to the correct element.
Changing this approach adds a lot of work by migrating existing e2e tests on playwright/cypress along with jest unit tests, so I want to ensure there wouldn't be a rollback in the nearest future.
Is this a final decision about data-test attributes?
@KaelWD can you chime in?
Vuetify clearly does not care about testability...
This issue exists for 5 years now. No progress so far. I will adivse my company/team and friends to not use Vuetify for serious applications in the future...
Not sure if this helps anyone with their E2E tests, but in component tests with Vue test utils, we got the select to open simply with:
const selectEl = wrapper.find(`[data-ref="${selectDataRef}"] .v-field`);
await selectEl.trigger('mousedown');
Also @MeikelLP, I'm sure the Vuetify team are open to contributions on this topic, if you'd care to take a moment to contribute, instead of complaining to people already offering their work for free.
Problem to solve
Test automation is key for DevOps. Whereas most (if not all) vuetify-components are automatable with selenium, ranorex, tosca & co, some do make live of a test automator unnecessary hard. The wish is: make each component in every configuration as easy automatable as possible.
Proposed solution
E.g. a select box:
results in the following html code:
The id went to the input which is not clickable, as it is readonly. You had to solve this with nasty xpath-give-me-your-parent-parent-magic:
$('//*[@id="country"]/..').click()
if the id was set to a clickable div, the automation code would be so much nicer and more readable:$('#country"').click()
Now I am aware, that this may be tricky. If the dropdown was typable, of course, having the id on the input were totally correct. So there is decision magic necessary.