Feature request: Mocking/stubbing sub-views

[yacuzo]

Hi,

I know this is heavily a work-in-progress library, but I also know you want feedback :)

Having used the ComponentTester for a few components we find the need for mocking/stubbing out sub-views which are imported through the html-require tag.

Prehaps a bit of background is helpful:
We have a separate suit of tests we call binding-tests. They are a form of regression-tests to avoid the problem of renaming view model properies and forgetting to rename the bindings in the HTML.
We want these as unit-tests so that we can get feedback asap.

This creates a problem where we have a component foo:

export class Foo {
  fooData;
  get processedFoo() {
    return processFoo();
  }
}

With html:

<template>
  <require from="some/path/bar" />
  <input value.bind="fooData" />

  <bar some-data.bind="processedFoo"></bar>
</template>

We want to check the binding for bar's 'some-data', but we do not want to parse the possibly complex output of bar in order to check that. Bar's output should not be a part of the test for Foo.

Is there a way to do this currently? Have you considered a use-case like this?

[EisenbergEffect]

I'd say, the best way to get something like this in would be to submit a PR with the proposed API.

However, for this specific scenario, it seems like you would just want to gain access to the view-model for bar and check it's property. That is possible, though a nicer API could be made available.

[yacuzo]

I dont want to check the property on the model. I want to check that my binding-expression in foo's template corresponds with something on the model. As I see it the best way to do this would be to mock out the bar-component, and check that the mock renders something other than undefined.

I'm not sure what the API for mocking out 'bar' would be. The ComponentTester.WithResources needs a way to override the require-tag in the template.

[suneelv]

We have very complex custom elements which require many other custom elements. To test any one of the complex custom element we had to mock the dependencies of all the other required custom elements which is not ideal.
As @yacuzo already mentioned, if the component tester provides a way to only render the top level custom element, then it would greatly reduce our element setup for testing.

[RomkeVdMeulen]

Exactly this. For example, say I have a component Mycomponent:

<template>
    <require from="./mysubcomponent"></require>

    <mysubcomponent if.bind="myData" data.bind="myData"></mysubcomponent>
</template>

I've already written a separate test for Mysubcomponent, mocking out services and the like. I don't want to have to mock out those same services again in my test of Mycomponent just to test whether the if.bind works as expected.

Is there some workaround to mock out mysubcomponent during the test of mycomponent?

[zewa666]

This pretty much sounds like a shallow rendering of the top level component and ditching childs. So essentially If we'd unregister the child elements they should be rendered as normal html.

[RomkeVdMeulen]

@zewa666 Any way to do that manually with the current API?

[zewa666]

We're currently looking into it to find the manual way. Will post back here and then go for a nicer overall API.

[RomkeVdMeulen]

@zewa666 Great! Thank you all for the prompt support.

[RomkeVdMeulen]

Any progress on this? I've been stubbing support for services used by subcomponents, and it's starting to become a bit tiresome.

[bigopon]

We can do this, via hooking to afterCompile, but how would the API would be like:

  .withResources('module1', {
    exclude: {
      elements: ['name1', 'name2']
    }
  }) 

or

  .withResources('...')
  .discardElements('name1', 'name2')

?

[zewa666]

How about .shallow() and exclude all internally?

[bigopon]

What about the <require/> statement, do we skip it entirely ? as when loading a module like foo.js to get custom element <foo/>, we might have additional resource to load ?