Skip to content
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

wrapper.emitted includes sub-component events with the same name #352

Closed
aethr opened this issue Feb 4, 2021 · 3 comments · Fixed by #354
Closed

wrapper.emitted includes sub-component events with the same name #352

aethr opened this issue Feb 4, 2021 · 3 comments · Fixed by #354
Labels
bug Something isn't working has-pr

Comments

@aethr
Copy link
Contributor

aethr commented Feb 4, 2021

Description

When testing component events, we often trigger an event on an inner sub-component to mimic user input, and observe a final event get emitted from the component under test, sometimes with a different / transformed value. However the current version of vue-test-utils-next makes this difficult by returning all emitted events with the same name, even if they were not emitted directly by the component under test.

This has become more of an issue with the recommendation not to use shallow mount, and the prevalence of update:modelValue events when using v-model heavily (ie in forms).

Expected behaviour

I would expect wrapper.emitted() to only include events emitted by the top-level component provided as the first argument to mount.

Observed behaviour

wrapper.emitted() includes events emitted from sub-components, adding to events observed under the same name.

Example

import { mount } from '@vue/test-utils';

const RawInput = {
  template: '<input v-model="computedValue" />',
  emits: ['update:modelValue'],
  props: ['modelValue'],
  computed: {
    computedValue: {
      get() { return this.modelValue; },
      set(val) { this.$emit('update:modelValue', val); },
    },
  },
};
const CSVInput = {
  template: '<div class="container"><RawInput v-model="computedValue" /></div>',
  components: { RawInput },
  emits: ['update:modelValue'],
  props: ['modelValue'],
  computed: {
    computedValue: {
      get() { return this.modelValue.join(' '); },
      set(val) { this.$emit('update:modelValue', val.split(',')); },
    },
  },
};

test('emitted events', () => {
  const wrapper = mount(CSVInput, { props: { modelValue: [] } });
  // inner component emits 'foo,bar'
  wrapper.get('input').setValue('foo,bar');

  // we want to test outer component emits ['foo', 'bar']
  expect(wrapper.emitted('update:modelValue')).toStrictEqual([[['foo', 'bar']]]);

  // instead wrapper.emitted('update:modelValue') contains events for both
  // inner and outer components
});
Error: expect(received).toStrictEqual(expected) // deep equality

- Expected
+ Received

@@ -1,7 +1,10 @@
  Array [
    Array [
+     "foo,bar",
+   ],
+   Array [
      Array [
        "foo",
        "bar",
      ],
    ],

Version

2.0.0-rc.0

This also appears to be a regression that was not present in earlier versions, as updating to 2.0.0-rc.0 broke about 12 tests in our test suite that were previously working with the expected behaviour.

@afontcu
Copy link
Member

afontcu commented Feb 4, 2021

Hi! This definitely looks like something that should not happen. Is it possibly due to #296?

@aethr
Copy link
Contributor Author

aethr commented Feb 4, 2021

Looks like it. The devTools emit method is getting called on every emit, so all events occurring within the wrapper are being recorded.

A simple fix would be to add a key to each vm to record events for each vm separately, not sure if polluting the vm instance is considered bad form. Alternately, events could be recorded against the component uid.

I can take a look at getting a PR up tomorrow if no one else has a chance to look at it.

@aethr
Copy link
Contributor Author

aethr commented Feb 5, 2021

Had a crack at a PR, updated the tests to detect the issue but I haven't tested this fork against my actual project codebase.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working has-pr
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants