Skip to content

Allow custom attribute in the Wrapper.find options object. #677

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
adamwoodbury opened this issue Jun 1, 2018 · 7 comments
Closed

Allow custom attribute in the Wrapper.find options object. #677

adamwoodbury opened this issue Jun 1, 2018 · 7 comments
Assignees

Comments

@adamwoodbury
Copy link

What problem does this feature solve?

This would allow the tester to access the Wrapper instance of a child component using a custom attribute query.

Consider the following template.

<div>
  <custom-component ref="1"/>
  <custom-component ref="2"/>
  <custom-component ref="3"/>
</div>

I can use wrapper.find({ ref }) to access the Wrapper instance of a specific <custom-component>. If instead I have some other custom attribute that is already in use in conjunction with another testing framework, I have no way to access the Wrapper instance of a specific component.

Consider instead this template:

<div>
  <custom-component selenium="1"/>
  <custom-component selenium="2"/>
  <custom-component selenium="3"/>
</div>

It would be nice if I could do something like wrapper.find({ selenium: '1' }) to get the Wrapper instance of the first <custom-component>.

What does the proposed API look like?

wrapper.find({ 'custom-attribute-name': 'custom atrribute value' });

@38elements
Copy link
Contributor

I think this feature is resolved by using the CSS attribute selector.
Therefore, I think that it is unnecessary to add this feature.

const TestComponent = { 
  template: '<div>{{ foo }}<child-component foo="bar" /></div>',
}
const wrapper = shallowMount(TestComponent)
expect(wrapper.find('[foo="bar"]').html()).to.equal('<child-component foo="bar"></child-component>')

@adamwoodbury
Copy link
Author

adamwoodbury commented Jun 4, 2018

When you use a CSS selector it doesn't return the same thing:

test('find component', () => {
  const wrapper = mount(Component)
  expect(wrapper.find(ChildComponent).props()).toMatchSnapshot() // returns VueWrapper instance
})

// gives error: [vue-test-utils]: wrapper.props() must be called on a Vue instance
test('find with css', () => {
  const wrapper = mount(Component)
  expect(wrapper.find('[attribute="value"]').props()).toMatchSnapshot() // returns Wrapper instance
})

@38elements
Copy link
Contributor

38elements commented Jun 4, 2018

You can get the first Wrapper object.

https://vue-test-utils.vuejs.org/api/wrapper-array/#at-index

You can use filter method.

https://vue-test-utils.vuejs.org/api/wrapper-array/#filter-predicate

I think that it is unnecessary to add this feature.

@adamwoodbury
Copy link
Author

I still think the proposed API would be much nicer, even if it isn't strictly necessary:

expect(wrapper.find({ 'key': 'value' }).props()).toMatchSnapshot();

// vs

expect(
  wrapper
    .findAll(ComponentName)
    .filter(w => w.attributes().['key'] === 'value')
    .at(0)
    .props()
).toMatchSnapshot();

@lmiller1990
Copy link
Member

Adding more functionality to find just to be able to get make a snapshot assertion in a few less characters seems like it would be very difficult in terms of discovery - I think most people would be familiar with the find("[attr='val']") syntax - is there any other use cases for this? If so, we can consider it, but if not, I'm leaning towards not including this feature. Do you have any thoughts @adamwoodbury ? (if you still use VTU, that is, this issue is a bit old)

@lmiller1990 lmiller1990 self-assigned this Jan 8, 2020
@afontcu
Copy link
Member

afontcu commented Jan 9, 2020

I'd also say using the CSS attribute selector is a better solution, since it's the standard way of performing this queries – also we avoid introducing additional unnecessary complexity to VTU 👍

@lmiller1990
Copy link
Member

Going to close this one for now. Thanks for the proposal but unfortunately this feature won't be added at this point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants