0

I have an Angular project where I use the Clarity Design UI framework. My project uses Clarity's DataGrid component and listens to its clrDgRefresh EventEmitter which triggers in response to changes in the underlying data or user interactions. I'm writing tests for a component that involves changes that trigger this EventEmitter and I'm trying to figure out how to stub the callback on these events so that they are not triggered during testing. How can I do this?

My component template contains 

<clr-datagrid (clrDgRefresh)="dgRefresh($event)">

where the @Output on Clarity's DataGrid component is

@Output('clrDgRefresh') public refresh = new EventEmitter<ClrDatagridStateInterface<T>>(false);

and my component has something like 

@Debounce(400)
dgRefresh(event: any) {
  this.doSomething();
}

where I want to stub doSomething in tests (or just prevent it from being called).

My spec file has:

TestBed.configureTestingModule({
      imports: [
        ClarityModule,
        ...
      ],
      ...
    })
    .compileComponents();

I can't just spyOn(component, 'doSomething') since it only stubs direct calls to the function and not those triggered asynchronously through Clarity. I also can't do something like this since I'm using the entire module and not just a single component.

I also tried to get the instance of the DataGrid component that is created within my component and stub that with

let datagridDebugElement = fixture.debugElement.query(By.css('.datagrid'));
let datagrid = datagridDebugElement.componentInstance;
spyOn(datagrid, 'refresh');

But that also doesn't work (doSomething is still called). What's the right way to approach this?

ARM
  • 1,520
  • 1
  • 12
  • 24
  • Can you `spyOn(myComponent, 'dgRefresh').and.doNothing());`? (or maybe `and.callFake(() => myFakeCallback());` – The Head Rush May 02 '19 at 18:36
  • @TheHeadRush I run into https://stackoverflow.com/questions/49396736/can-webpack-4-modules-be-configured-as-to-allow-jasmine-to-spy-on-their-members/54757283#54757283 – ARM May 02 '19 at 19:47
  • Can you help me understand a bit more. It seems like the application needs to disable the `clrDgRefresh` @Output but only in a test. I'm unsure why an application would need to do this. Is there any way you can show a recreation or simplified version of your test? Stackblitz or github repo? – hippeelee May 06 '19 at 15:26
  • Our application allows cross-filtering between some plots and a datagrid that shows the underlying data. We listen to `clrDgRefresh` to see when the user applies some new filters to the datagrid. Once this happens we apply all the datagrid filters to the raw data to figure out what data is now accessible (a workaround to https://github.com/vmware/clarity/issues/253) and then update our plots using the filtered data. – ARM May 06 '19 at 16:34
  • The problem is that `clrDgRefresh` is emitted not only in response to user actions, but also by things like adding data to the table. Our plotting process involves calling an API to do some fitting and we want to stub this in tests. I actually have a demo repo that does something very similar to this -- I'll update it to the latest Clarity release and add it here. – ARM May 06 '19 at 16:42

0 Answers0