-
Notifications
You must be signed in to change notification settings - Fork 264
Finalize API #17
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
Comments
Great summary, here are my thoughts.
Mount Options
|
Hey! :) 👋 In face of doubt, I’d go with “deprecate”. I’d focus on having a single, simple way of doing things, and let userland provide additional modules/plug-in systems if needed. So for instance:
Totally in favor of deprecating + providing the right docs to showcase how to test such scenarions. My two cents: Assertion-like methodsWe have several methods that are simply assertions. Could be remove them altogether – as long as users can assert the same stuff? Examples:
Other methods / attributes
and I’m gonna drop the bomb:
|
If I recall correctly, docs didn’t cover that you can pass |
I am keen to deprecate few things:
For
I find I'll do a summary and draft an RFC. |
I think
Same thing with 👍 with import { mount, html } from '@vue/test-utils'
test('whatever', () => {
const wrapper = mount(Comp)
html(wrapper) // or similar API, whatever. it could also accept a WrapperArray
// ...
}) |
I have not looked into the Importing I don't have a strong opinion either way, but we should be mindful some people have very large test suites they will want to migrate. |
If feasible, I'd go with a single |
That should be easy to implement - we just have I think this should be a (separate) RFC to the deprecation ones. A smaller, more simple API is definitely attractive to me. |
I thought about
People want to test that when People like to test these in isolation, though. Is there some other way to test this other than |
Simulating setPropsSolution: Mount the component as a child of another component, and change the prop from there. Makes the test a bit more convoluted, but not impossible, explained it in my first response. Clases, html, name etcYou want users to not have access to Something to think about probably, or at least ask users for opinion. setValue, setChecked and the likeI rarely use them personally, though I can see the appeal to if not remove, to reduce to a generic method. Example: I am testing my wrapper component around some Image SVG cropping tool. I should not need to dig inside the component to find which inputs to trigger an event against, as that could make my test fail if the developers changes internals. I should be able to just target the Vue component and Maybe an API like this could work?
|
update: it should :) just updated the comment |
Should we close this up and wait for the public RFC to evolve? We can then match both our initial expectations and the outcome, and come up with a plan of features and releases 🙌 |
Sounds good |
Uh oh!
There was an error while loading. Please reload this page.
Let's agree on a basic API and make an RFC so everyone can express their thoughts.
Proposed Wrapper API
nextTick
. So you can doawait wrapper.find('#button').trigger('click')
. Nice!trigger
trigger
trigger
Wrapper API - Deprecations
find
- can we combine them?tagName
propertydata
mounting option to set a specific state.setData
,setMethods
toContain
Mounting Options - Proposed API
slots
.app.mixin
, since you no longer attach these to Vue.prototypeapp.mixin
, since you no longer attach these to Vue.prototypeThe text was updated successfully, but these errors were encountered: