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

To do before release #246

Closed
10 of 13 tasks
eddyerburgh opened this issue Dec 9, 2017 · 33 comments
Closed
10 of 13 tasks

To do before release #246

eddyerburgh opened this issue Dec 9, 2017 · 33 comments

Comments

@eddyerburgh
Copy link
Member

eddyerburgh commented Dec 9, 2017

Hi guys, vue-test-utils has been in beta for a couple months now, and the feedback we've got has been really helpful.

There are a few things left to do before we release 1.0.0:

If anyone has any additional items they think should be added to the list, leave a comment 🙂

@eddyerburgh eddyerburgh changed the title To do before releawse To do before release Dec 9, 2017
@lmiller1990
Copy link
Member

I think you have the wrong issue reference for Add docs for testing components that have asynchronous calls ?

I am interested in writing docs for this! This basically refers to anything using async or a Promise, right?

Maybe we can put it under the guides section.

@eddyerburgh
Copy link
Member Author

Yes, I think we should add it to the guides section. That would be great if you could write it 🙂

@lmiller1990
Copy link
Member

lmiller1990 commented Dec 14, 2017

I would like to do this, I will have time after the 19th.

Edit: started here https://github.com/lmiller1990/vue-test-utils/blob/add-async-guide/docs/en/guides/testing-async-components.md

Also, I think we should add something about what to test. A lot of people have problems, when they are testing things using vue test utils that it shouldn't be used for (like testing other people's components).

Not directly related to this library, but I think providing an official library that will become a big part of the ecosystem, some solid guides on how to use it, and not just what it does but what it does not/should not do would be valuable.

I gave a presentation last night about vue-test-utils at v-meetup in Tokyo, and talked to a bunch of people, and one of the main feedback points was "better ways to select things, like calendar inputs".

I think what people are doing is unit testing components that have child components which wrap and , which I don't think should be the job of vue-test-utils (unless of course you are authoring a input wrapper component). The line between unit tests and integration tests is pretty blurred for a lot of people.

@eddyerburgh
Copy link
Member Author

Yeah I agree, I'll add it to the list

@38elements
Copy link
Contributor

IMHO,
I think it is better that Add docs on what/ how to test is in cookbook.

@lmiller1990
Copy link
Member

lmiller1990 commented Dec 20, 2017

@38elements I can see your line of thinking. I feel like some test specific guides, with lots of details, would be great to include with vue-test-utils docs, and some more general ones referring to vue-test-utils in the cookbook.

I made PR #282 with a detailed guide about async components, but something more general I think would be great. I'll post in the cookbook repo. Thanks for your input!

@robcresswell
Copy link
Contributor

Is it possible to get beta.9 released in the meantime? Having .attributes() broken is a bit of pain 😄

@eddyerburgh
Copy link
Member Author

@robcresswell just released

@38elements
Copy link
Contributor

Would you please update document page?

@robcresswell
Copy link
Contributor

Great work @eddyerburgh !

@ghost
Copy link

ghost commented Jan 18, 2018

Is there a bug on functional components or I'm missing something?

<template functional> or <script>export default { functional: true }</script> doesn't work.

mount.context can only be used when mounting a functional component

@eddyerburgh
Copy link
Member Author

eddyerburgh commented Jan 18, 2018 via email

@ghost
Copy link

ghost commented Oct 26, 2018

Given that the last update on the progress here was almost a year ago, I am interested in the current state of this.

@eddyerburgh Is the checklist in the issue description still accurate and are those the only blockers for the 1.0 release? Are there specific tasks that could need help to speed up the release?

@eddyerburgh
Copy link
Member Author

eddyerburgh commented Oct 26, 2018

These are the two blockers:

  • Improve support for extended components
  • Fix synchronous bugs

The synchronous bugs will be fixed with a small amount of work after the next Vue version is released.

The support for extended components is a major issue, and might require a change to how the library works. Currently we extend components from a Vue constructor that includes added instance proeprties/ stubs. This is fine for component option objects, but Vue.extend is not intended to be used with a constructor function. This has lead to a few bugs that are difficult to fix.

Apart from that there are a few smaller bugs that could be fixed (like #973). I would appreciate help with them, but they aren't blocking from release.

@ghost
Copy link

ghost commented Oct 26, 2018

Thank you @eddyerburgh, much appreciated! 😃

@divasatanica
Copy link

Improve support for extended components

I'm now trying to integrate the unit test feature using vue-test-utils into a cli tools.But it was blocking by the issue above because we use typescript and vue-class-component in project.
WISH you guys can fix it. FIGHTING!!

@pipopotamasu
Copy link

pipopotamasu commented Jun 28, 2019

@eddyerburgh I really enjoy using vue-test-utils and am looking forward to release!

However, I am not sure two blockers causes and solutions so I want to clarify them.

Improve support for extended components

Cause

You mean below.

Vue.extend is not intended to be used with a constructor function. This has lead to a few bugs that are difficult to fix.

In my understanding...

// OK: intended usage
const BaseComponent = Vue.extend({
  ~~~~~~ some options ~~~~~~
});

// NG: not intended usage
const ChildComponent = new BaseComponent({
  ~~~~~~ some options ~~~~~~
})

Is it correct?

Solution

You are trying to solve this problem by below issue.
#1084

Fix synchronous bugs

Cause

sync mode of vue-test-utils.

However, you mean ...

The synchronous bugs will be fixed with a small amount of work after the next Vue version is released.

I am not sure what next Vue version(version 3?) brings.
→ I found this PR. You meaned Vue async option!

Solution

below issue.
#1137

@Mikilll94
Copy link

When will be the stable version released?

@lmiller1990
Copy link
Member

Probably when these are fixed https://github.com/vuejs/vue-test-utils/projects/1. Ideally before Vue 3 comes out. We also need to work on Vue 3 compat.

Is there a specific feature or bugfix you are waiting for? Although in "beta", all the important features and present and many people are successfully using it in production.

@telion2
Copy link

telion2 commented Apr 2, 2020

The problem is that our customers don't trust packages that are in beta as a general policy. I personally think this is a great project, especially since I dont find a simple way to unit test without it.
It is also mentioned in all the official docs, tutorials etc. so good job there.

So I have 2 questions:

  • Is solving the mentioned blockers really necessary for a release?
  • The same as @Mikilll94 "When will be the stable version released?" as I dont see, if the tickets are planned soon, or how long they would take to fix.

I don't intend to pressure anything, rather trying to find out what decision to make.

@Mikilll94
Copy link

Mikilll94 commented Apr 2, 2020

@telion2
Exactly. For me it is very strange that almost all Vue tutorial, official Vue docs, official Vuetify docs etc. mention this package although it is in beta. Even Vue CLI add this package to the project if we select "unit tests".

Most programmers and companies generally don't trust beta packages and this generally not a good practice to use beta software in production.

@lmiller1990
Copy link
Member

lmiller1990 commented Apr 3, 2020

I'm surprised your customers are looking at the devDependencies in your projects. That's a good thing, I guess!

Anyway, I agree. I think we can look at a 1.0 after the PRs are merged.

And call it 1.0. We could say 2.x will be Vue 3 support. Let me ask some other contributors to make sure everyone is on board: @JessicaSachs @afontcu and @dobromir-hristov

This reason this was in beta for so long was a variety of reasons:

  • bugs with sync mode
  • removal of sync mode
  • extreme complexity of some features, mainly owning to how we implemented shallowMount (hacking $createElement)

A lot was learned! I hope we can do a better job for 3.x. That said, I thin this lib is in a good enough place for a 1.0 and has helped us understand how people would like to test their components.

1.0 means no more API changes. 2.x will likely have a slightly different API, since Vue 3 internals changed a bit, and some things don't make much sense (createLocalVue and mocks, since attaching to the prototype will be less common).

Anyway, I will get you an answer to this question in the near future (days).

@telion2
Copy link

telion2 commented Apr 3, 2020

So looking into them, then the first two PRs only need a Review and the last one needs to upgrade vuetify related stuff. Thank you for the information and your time^^.
Really nice project. I like it ;)

@afontcu
Copy link
Member

afontcu commented Apr 3, 2020

I'm OK with shipping v1, this will leave us plenty of time and a stable context for v2.

by the way, #1309 looks like has some breaking changes, so I guess we should decide if tackle it before a proper 1.0 release.

Thanks for moving this forward! 🙌

@KajcsaErno
Copy link

KajcsaErno commented Apr 3, 2020

I can't wait for the release. Thanks for the effort and for creating such a great project.

@lmiller1990
Copy link
Member

I can't gauge how important it is to merge #1309. I never use shallowMount - is this an important one to merged up?

If it's too breaking, we may just be better abandoning it. I think VTU has had enough breaking changes at this point.

@JessicaSachs
Copy link
Collaborator

I think we can omit this from the v1 release. There are two workarounds:

  1. use mount
  2. write your own stub that implements the named slots

@lmiller1990
Copy link
Member

Alright, after #1492 let's do v1. I'll follow up on it.

@telion2
Copy link

telion2 commented Apr 20, 2020

Hi there again.
The last beta release notes: "Note: this is the final beta. Next will be 1.0."
#1492 also looks like its merged.
Is there any holdup or PR that needs to be merged for the release? Thank you in advance!

@lmiller1990
Copy link
Member

In VTU next here we made some changes to the API:

  • when using find(Foo) when finding a component, you will now do findComponent(Foo). find will just be for DOM elements.
  • destroy is now named unmount (to match Vue 3 API change)
  • mocks and stubs are "global", so we moved them to a "global" API:
wrapper(Foo, {
  globals: {
    stubs: ...
    mocks: ...
  }
})

As opposed to things like data, which are local to the component.

I'd like to backport, or at least add deprecation warnings for these features before v1. I plan to do that this week sometime.

  • add a "deprecation" for when people use find with a component. Also support findComponent as an alias to find.
  • add a globals key (support both mocks and globals.mocks for example). Deprecation message when using mocks (no global key)
  • deprecation message for destroy. Support unmount as an alias.

The updated VTU next is here.

If you are interested in making these changes, feel free to do so, and we can get things moving more quickly. Not strictly required for v1, but I think it will help people migrating to Vue 3.

@lmiller1990
Copy link
Member

Ok, once this RFC is merged in I will add deprecation warnings and release v1.

@afontcu
Copy link
Member

afontcu commented Jun 12, 2020

Looks like this issue can finally be closed!

@lmiller1990 you wrote the first comment back in 2017 – I think you should be the one closing it 😉

@lmiller1990
Copy link
Member

Great, closing!

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