MockControlValueAccessor: auto spy writeValue if a mock function was registered

[GerkinDev]

Hi,

In the context of one of my tests, I have an input that is displayed only if a value is set on my host component, and bound with this value. That means I can't retrieve the input with find or other methods before defining the actual value, and thus, I can't spy on its writeValue method.

By looking around in the code of ng-mocks, I saw that the jest and jasmine registers function for auto-mocking. Would it be possible to use this auto-mocking function instead of the stub function of writeValue ? And would it be pertinent to use auto-mock functions on other methods of the ControlValueAccessor interface ?

I'd be happy to PR. Kind of blocking me in my sprint, so I guess I'll have to fork anyway or skip this test altogether.

🍻 cheers !

[satanTime]

Hi @GerkinDev,

might you share the template's code, or a small project on codesandbox.io? Simply fork it.

Please correct me if I'm wrong. You have a component with control value accessor that is rendered under some circumstances and there's no direct access to it before the circumstances.

Currently I think you can use MockInstance, but the case about other methods of the interface is a good one and I'll try to find a solution for them out of the box with auto mocking too.

describe('test', () => {
  // spy we want to track
  const writeValue = jasmine.createSpy('writeValue');

  // injecting the spy into the desired component
  beforeAll(() => MockInstance(MyValueAccessorComponent, instance => {
    instance.writeValue = writeValue;
  }));

  // removing custom initialization from beforeAll
  afterAll(MockReset);

  beforeEach(() => MockBuilder(Component, Module));

  it('test', () => {
    const fixture = MockRender(Component);

    // default - not rendered
    expect(writeValue).not.toHaveBeenCalled();

    // creating circumstances
    fixture.point.componentInstance.condition = true;
    fixture.detectChanges();
    expect(writeValue).toHaveBeenCalledWith('foo');
  });
});

[GerkinDev]

Wow, GG, sorry, it actually does exactly what I want.

And I've (mostly) RTFM. I just missed this part, which is pretty far in the README. So I guess I'd just call myself silly lazy bastard, and say that I think it should be easier to find. Such a big README is not that easy to know where to look for what.

[GerkinDev]

Anyway, for reference, RTFM: https://github.com/ike18t/ng-mocks#mockinstance

[satanTime]

Yeah, agree, that's where I struggle too. Too many things to describe in documentation.

Might you describe how you read the documentation first time?
I think I can put a few words in one of the first paragraphs that grabs visitor's attention.

[GerkinDev]

Well, I'm gonna be totally honest with you: seeing the size of the readme, I read mostly code samples, headings, links and what is put on emphasis. There's just too much text to keep the full attention on the whole README. So I didn't really read pretty much everything else.

I would have expected to see something talking about it in the How to create a mock component section, since a form control is most of the times a component, even though a directive can also be one. And because I didn't found what I was looking for, I did a plain CTRL+F ⇒ ngModel, which lead me to How to create a mock form control where I found how to spy on an existing form control's writeValue method. But from there, I didn't have anywhere to go, except in the issues (:wave:)

I would have expected to have the following:

• A shorter readme with quick recipes on how to mock services, components, directives, etc etc, pretty much what is in How to turn annoying declarations into mocks in an Angular application, but with a shorter format like a quick reminder for people who already know the lib and just needs a head's up for memory to come back.
  • In the Component and Directives recipes, links to another part, and probably a totally different doc page with how to mock a form control
• A page explaining how to mock a form control, with more extensive examples since this would be in its own place, easily accessible when looking for it in the Component and Directive recipes. This may contain the solution given above, with a link to the detailed section about MockInstance

---

TL;DR

There is REALLY too much text and too few cross-references between sections, or examples on more precise cases. But adding examples would again increase the README size, and that is, IMHO, not an option.

I guess the wiki, with a clear table of content easily reachable from the side, would be a pretty decent solution without having to build a complete docs site (even if there is already one, but it is, unfortunately, mostly useless in its current form IMHO 😞)

[satanTime]

Hi @GerkinDev,

I totally agree with your feedback and thank you for being honest. Unfortunately, the biggest problem is available time for the project, that's why website has only simple examples and all docs are in the readme. It will be a wiki one day, the only question is when :)

The current intention was to attract people:

• to "Motivation and easy start", briefly explaining basic usage
• then main functions
• then "Extensive example"
• then to convince them to check an online sandbox, or to ask a question on gitter or here in issues

But users have own ways 😄

Anyway, back to the business.
Might you verify that it works as you expect: ng-mocks.zip

And I would appreciate your feedback on the next 2 questions:

1. Component and Directive sections have the "NOTE" part now.
   https://github.com/satanTime/ng-mocks/tree/issues/246#how-to-create-a-mock-component
   https://github.com/satanTime/ng-mocks/tree/issues/246#how-to-create-a-mock-directive
   Would it work better? not sure if it's possible to change that gray color.

2. I extended example for forms exactly with your case, instead of install a spy in the middle.
   https://github.com/satanTime/ng-mocks/tree/issues/246#how-to-create-a-mock-form-control
   Have you ever realised these hidden blocks with code samples? I always wonder wether people see them 😃
   Would it be better simply to post links to the source files and an online sandbox?

Thank you in advance!

[satanTime]

Hi @GerkinDev, might you check the comment above?

[GerkinDev]

Hi,

Changes are OK IMO :) and yes, I've seen the collapsibles that greatly reduce the size of the readme; great compromise I think, and easy enough to spot. But maybe using headings in the collapsible summaries would make them easier to spot (and list in a TOC).

Great job <3

[satanTime]

HI @GerkinDev, thanks for the feedback, I'll try to implement it in near future.

[satanTime]

v11.2.3 has been released and contains a fix for the issue. Feel free to reopen the issue or to submit a new one if you meet any problems.

[satanTime]

Hi @GerkinDev,

I hope this finds you well and healthy!

I've created a separate website for documentation, might you check if it fits your expectations?
https://ng-mocks.sudo.eu/