initial data & setData for composite & class components #1880
Conversation
✅ Deploy Preview for vue-test-utils-docs ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
There was a problem hiding this comment.
As I mentioned in #1879 , I don't think supporting setData/initial data on components written with Composition API really makes sense, as the data field no longer exists in these components.
But I don't think strongly about it. @lmiller1990 @freakzlike what do you think ?
The same thing can be achieved via wrapper.vm.prop = value
| } | ||
| }) | ||
|
|
||
| app.mixin(mixin) |
There was a problem hiding this comment.
Wouldn't this be called for every component? Not only the component which has been passed to mount
There was a problem hiding this comment.
you are right, as i added this as a mixin it will be called for every component in this App.
I will have a look if there is another convenient way to set the data fields.
|
I agree with @cexbrayat, Is there a case where you can't test your component without a Another concern is that one of the explicit goals of the Script Setup is closed by default. Are we going against a design decision? Recently we've been broken a bunch of times by core changes - maybe this is a sign Test Utils is overstepping it's bounds. The way Vue recommends exposing those is via
So, if we support this, would it makes sense to call it |
|
Left a comment ^ Interested in this but would like to at least discuss a tiny bit more - any new feature is more complexity and maintenance so we should carefully consider based on use cases, edge cases, back/forward compatibility, etc. |
We've recently migrated from Vue 2 to Vue 3 and are embracing knowing what to test given the changes when moving to the Composition API. It's been quite a mentality switch from our 100% line coverage approach in the Options API. Today, I may have run into such a case where having access to the underlying data in the setup() would be helpful, if not necessary. I'm trying to write tests around a file input component. The file input's value cannot be directly modified for security reasons:
I'm having trouble figuring out how to get the input populated with a File() object in our tests so I can test various things (validation, the file being passed through to an API call upon form submission, etc.). Any thoughts on how to bridge this gap would be appreciated, but it may be the use-case you're looking for. I should also mention that while we have been able to adapt to the idea that we have to emulate user actions to set values in controls, i.e. element.trigger('click'), element.setValue('foo'), etc, there's a noticeable friction in this testing when compared to the old methodology. As an example, Vuetify 3.1 recently made some changes to some of their controls and layouts that are really unimportant to us from an implementation standpoint. They changed some of the control activation events from "click" to "mousedown". These have the same effect in a browser and are almost entirely transparent to the user. For us developers, this means our tests failed upon upgrade and we had to refactor our emulated user actions. In the Options API, we would have just set the data directly with the expectation that our controls' internals are unimportant. Locating elements used in Teleports is another such example. Instead of finding an array of elements and clicking on all of them, we would've just set the data to an array in our tests. Admittedly, the new approach gives us the stronger assertion that our controls are correctly tied to data elements because we're forced to interact with the control to engage the data. |
|
Coincidentally, I may have stumbled on a second use-case. We have a component that allows for updating a resource server-side. When that resource is updated, the change is logged. On the front-end, we have a View that renders both that resource and the log of the changes to the resource. When the resource is changed, we also want to have the log events on page get refreshed. The log events rendering is abstracted into its own separate component. To facilitate the forced re-render, we're using they key-changing technique. Within our tests for the main View, the log component is stubbed. The testing for the log component is separated. Our snapshots in the main View contain the stubbed representation of our log component, but because there is no representation of the |
|
Superseeded by #2166 |
I want to be able to use
setDataandmount/shallowmountdata: () => {}callbacks to modify data in my composite and class components.This should handle:
and maby Bug: setData with classes/Object prototypes does not work correctly #1851 as well