Skip to content

Cannot stub sub-child-component on mounted #682

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.

Sign up for GitHub

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

Jump to bottom
Closed
trollepierre opened this issue Jun 5, 2018 · 5 comments
Closed

Cannot stub sub-child-component on mounted #682

trollepierre opened this issue Jun 5, 2018 · 5 comments
Labels
bug

Comments

@trollepierre
Copy link
Contributor

Version

1.0.0-beta.16

Reproduction link

https://codesandbox.io/s/9z96nkvyor

Steps to reproduce

My TestComponent has a ChildComponent that I want to test (to add in my snapshot, because it's a slot template)
My ChildComponent contains an AppHeader, that I want to stub (so my snap should not depend on it)
I am mounting with some stubs:

const wrapper = mount(TestComponent, {
        stubs,
      });
const stubs = {
        AppHeader: '<div class="stub-appheader"/>'
      };

But the AppHeader is not stubbed in my test

What is expected?

I expect to generate a component with sub-component that can be stubbed

What is actually happening?

Sub-component are not stubbed
@lmiller1990
Copy link
Member

lmiller1990 commented Jun 5, 2018 •
edited
Loading

I think this is similar to this other issue #649

At the moment, stubs only works on the components declared in the component you pass to shallowMount and mount. I think we need to implement the dive or depth idea suggested in the above issue.

I generally find using mount generates a better snapshot that catches more errors. In practice, your component does depend on the children it renders, so I think using mount is a more accurate and useful way to use snapshots.

Is there a particular reason you can't use mount? Until we implement the depth feature, I think that's the best (only?) way to accomplish what you are trying to achieve.

@eddyerburgh eddyerburgh added the bug label Jun 5, 2018
@trollepierre
Copy link
Contributor Author

trollepierre commented Jun 5, 2018 via email •
edited
Loading

@eddyerburgh eddyerburgh mentioned this issue Jun 14, 2018
Closed
@cdbkr
Copy link
Contributor

cdbkr commented Jun 15, 2018

imho, dive and depth would be nice to have but not related to this bug and wouldn't help jest snapshots, would they?
Consider the following:

<Header/>
<Body>
  <LazyLoaded/>
  <Cards>
      <Card/>
      .....
  </Cards>
</Body>
<Footer/>

I'd like to stub only LazyLoaded because I am not interested into it, and I'd like the snapshots rendering the whole tree except LazyLoaded (because of something I don't really care)...

@lmiller1990
Copy link
Member

lmiller1990 commented Jun 15, 2018 •
edited
Loading

Maybe I am not using snapshots correctly, but to me, snapshots should capture the entire dom as rendered, aka actual html elements like <div>, <input> etc, not custom components. At least from my point of view, the snapshot should contain the actual dom that will be rendered in the browser, so you should use mount, not shallowMount. I want to know if my the actual dom I'm sending to the browser is correct or not.

If you want to make sure <Body>, <Cards> and <Card> are rendered, write this:

const wrapper = shallowMount(Foo)

expect(wrapper.find({ name: "Body" }).exists()).toBe(true)
expect(wrapper.find({ name: "Cards" }).exists()).toBe(true)
expect(wrapper.findAll({ name: "Card" })).toHaveLength(4)

This kind of test makes it much more clear what should and shouldn't exist that a snapshot test. If one of the components suddenly disappears you will get an error like " should exists, but doesn't" instead of having to manually compare two snapshots and try to figure out what's going on.

Instead of going out of your way to avoid testing something you don't care about, just focus on testing what you do care about.

@eddyerburgh
Copy link
Member

Whatever your preference for snapshot tests, this is a bug that we'll fix

@eddyerburgh eddyerburgh mentioned this issue Jun 15, 2018
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@cdbkr @trollepierre @eddyerburgh @lmiller1990