[Documentation - Angular] What is the best practice for spying on component methods?

[CMadden8]

I've seen the below from the docs, but is this really the only way of spying on the component methods?

.then((wrapper) => {
    console.log({ wrapper })
    cy.spy(wrapper.component.change, 'emit').as('changeSpy')
    return cy.wrap(wrapper).as('angular')
  })

The component testing feature is very good in general - I'm trying to switch our team's unit tests from Jest to Cypress component testing. But the documentation is quite slim in terms of content/examples...

Generally you want to spy on the component's methods, rather than the component's outputs (which seems to be the focus of the documentation, for some reason...). I find outputs are rarely used, even without something like ngrx.

Yet the docs focus on auto-creation of output spies, or creation of output spies via the mount config. Cool, but what about the more common methods you want to spy on - the methods on the component itself?

I'm not trying to be a smartass, but I think this should be the focus of the documentation, as auto-creation of spies for component methods would be a million times more useful than output spies. In particular I think the documentation should give us more examples of even a basic version of how to do this.

It's a very promising alternative to Jest etc - and it's working great so far... But the documentation could use some further effort IMO.

Even googling around, there are virtually no useful examples on how to unit test what you 99% of the time want to unit test: spying on the methods of the components themselves...

[jordanpowell88]

@CMadden8 I think you raise an interesting slim area in our documentation around this. Certainly you can spy on any public of the Component Class. The reason "why" we don't have recommendations around this in general is that ideally tests aren't tied to the methods of the class but the side effects those methods have on the UI itself. For example:

export class ButtonComponent {
  @Input() type: 'primary' | 'secondary' | 'danger' | 'outline' = 'primary'
  
  getStyles(): string {
    let styles =
      'items-center py-2 px-4 text-sm font-medium text-center rounded-lg focus:ring-4 focus:outline-none';
    switch (this.type) {
      case 'primary':
        styles +=
          ' text-white bg-blue-700 hover:bg-blue-800 focus:ring-blue-300';
        break;
      case 'secondary':
        styles +=
          ' text-gray-800 bg-gray-100 hover:bg-gray-200 focus:ring-gray-300';
        break;
      case 'danger':
        styles += ' text-white bg-red-600 hover:bg-red-700 focus:ring-red-300';
        break;
      case 'outline':
        styles +=
          ' text-gray-800 bg-gray-200/10 hover:bg-gray-200/75 focus:ring-gray-300 border border-gray-300';
    }
    return styles;
  }
}

Given the example Component above we could write a test that validates the getStyles() method of the ButtonComponent returns the expected style given a specific type @Input(). This is how many jest unit tests were written previously. And you CAN write tests like this in Component Testing.

Alternatively, we could write a similar test using a different approach with Component Testing:

  it('valididates the correct style of gray given type outline', () => {
    cy.mount(ButtonComponent, {
      componentProperties: {
        type: 'outline'
      }
    })
    
    cy.get('button').should('have.class',  'ext-gray-800 bg-gray-200/10 hover:bg-gray-200/75 focus:ring-gray-300 border border-gray-300')
  });

Does this help provide any clarity?

[dave-morgan]

I have stumbled upon this same issue trying to find an answer. I want to validate that a service method is called from a button push. This could be something like triggering update to state. The ability to spy on methods is crucial to test service calls.

it('increments state on button click', () => {
  cy.mount(PageComponent, {
    providers: [StateService], 
  }).then((wrapper) => {
    cy.spy(wrapper.component.stateService, 'increment').as('incrementSpy');
    return cy.wrap(wrapper).as('angular');
  });
   cy.get('button').click();
   cy.get('@incrementSpy').should('have.been.called');
});

[CMadden8]

@jordanpowell88 Thanks for the reply - I'm only seeing this now, for some reason. I get what you're saying, but for example a common test is simulating a button click and testing that a spy called appropriately as in the above example by @dave-morgan .

it('should call myMethod when the button is clicked', () => {
    spyOn(component, 'myMethod');
    const button = fixture.debugElement.query(By.css('button')).nativeElement;
    button.click();
    expect(component.myMethod).toHaveBeenCalled();
  });

An @Input change is only one way to trigger 'side effects'. I see the example you provided is checking a DOM change - I agree with that, but would always have tested the spied method as well.

Given the convenience of assigning spies to Inputs with componentProperties, I would have thought it would make sense to also allow for a similar feature to spy on component methods...

On a side note, when using the then pattern of spying on methods, ngOnInit must be manually called if the test is checking a method is called correctly on init. You didn't need to do that with Jest, so I'm not sure if that's intended or not...

[jordanpowell88]

We generally don't recommend testing component internals like we would do in Jest. There are several reasons for this.

1. User's are unaware of your internal methods and therefore testing them has no direct correlation to your users. Internal methods of your components are essentially like a private API for the component. The component Input and Output properties are the public API of your components. Those public API properties and any Internal methods that trigger side effects for your users are areas you want to ideally add tests for.
2. When you test the internal methods of your component's those tests will inevitable break during refactoring. See this blog article I wrote about this. If you write test against the DOM, internal refactors will not break your tests!

With that being said, you are correct that calling .then on the mounted component does yield you access to the component instance. So you are more than welcome to test your internals as you see fit. In your example above you certainly could spy on any of the internal methods using this approach.

[CMadden8]

1. It's not recommended to test private methods (and you can't in Jest), but it is recommended, at least in Jest, to spy on and test public methods. IMO E2E tests are for testing user interactions - unit tests are to test the 'internals' that E2E cannot access. The unit tests in other words are to test the dev's expectations. Ie - Button A is clicked, Filter Option B is selected, apiCallA() is called with the relevant params. I don't see the point in having unit tests that ape the E2E tests.

2. Yeah, exactly - that's the whole the point of unit testing the internals. We refactor, possibly clean up some code, and devs need the safety-net of the unit tests to ensure the component continues to meet previous expectations. It's very easy to introduce a typo or unintended consequence during refactoring that breaks the test as you said - which is great. Without the warning/error, I would have missed it and now the above scenario is potentially calling the wrong endpoint (in fact I currently have component that 100% needs these kind of internal tests due to convoluted business logic)...

We seem to be in disagreement re: the separation of concerns between E2E and unit tests. It is at least useful that we can emulate the Jest philosophy of testing the 'internals' in a somewhat unsupported way.

However, I believe this strongly opinionated approach towards Cypress component tests will work against its adoption in the end. I'm nearly certain I have read that Cypress E2E does not have an opinionated approach to E2E (hence gherkin/cucumber as an optional plugin). So why the change for component testing?

It would seem a better approach to allow devs to choose how they define the unit tests as well, and to provide the tools to support multiple approaches. That is of course up to yourselves - but you unnecessarily limit adoption by insisting on the rules.

[mmcgee-aya]

Sorry, simple question can you spy on service calls in a component test? I can't get it to work. I will read this whole thread now

[dave-morgan]

I don’t think so. At least I have not been about to get it to work even though it would seem to be possible if the service is provided. From the comments it would appear this things like this are not the goal of cypress component testing. At this point I would see it as feature incomplete and I don’t understand why.

[jordanpowell88]

Yes you can. You would just need to inject the service see an example here. And then you can use cy.spy() to spy on the method(s) you want to validate