I've been tasked with writing tests for a chat app developed with Angular. Below is the snippet of Angular template code I'm currently writing tests for:
<div class="title-menu-container" fxLayoutAlign="center center">
<button id="save-title-button" mat-icon-button *ngIf="titleInputEdit; else settings">
<mat-icon class="secondary-text" (click)="saveTitle(titleInput.value)">check</mat-icon>
</button>
<ng-template #settings>
<button mat-icon-button [matMenuTriggerFor]="menu" [disabled]="!(isGroupConversation$ | async)">
<mat-icon class="secondary-text">settings</mat-icon>
</button>
</ng-template>
</div>
Essentially, if the component boolean variable 'titleInputEdit' is true, the save-title-button is displayed, otherwise the settings button is displayed. Here is the test case that is causing problems:
it('save title button should be present', () => {
component.titleInputEdit = true;
fixture.detectChanges();
expect(fixture.nativeElement.querySelector('#save-title-button')).not.toBe(null);
});
I simply "mock" the component variable, call .detectChanges(), and then test for the presence of the button. However, the test fails with 'Expected null not to be null.'
Through various console.log calls, I have confirmed that the component.titleInputEdit is correctly set to true but the fixture.nativeElement DOES NOT contain the correct button.
Some things I have noticed:
If I move the 'component.titleInputEdit = true' line into my beforeEach and remove it, and the detectChanges() call, from my test, the test passes.
beforeEach(() => {
fixture = TestBed.createComponent(TestComponent);
component = fixture.componentInstance;
component.titleInputEdit = true
fixture.detectChanges();
debugElement = fixture.debugElement;
});
it('save title button should be present', () => {
expect(fixture.nativeElement.querySelector('#save-title-button')).not.toBe(null);
});
If I remove the .detectChanges() call from beforeEach(), and leave it in the test case, the test passes.
I'm relatively new to Angular, but I've found instances of people with a similar issue. After trying some of the things recommended in those posts I'm still left scratching my head. What's even stranger is that I have written tests for other Angular components that do almost the exact same thing with no issue.
The example provided in the Angular docs show something very similar as well:
it('should display a different test title', () => {
component.title = 'Test Title';
fixture.detectChanges();
expect(h1.textContent).toContain('Test Title');
});
It turns out this is due to using ChangeDetectionStrategy.OnPush
in the component. Using OnPush
only allows you to call .detectChanges()
one time, so subsequent calls will fail to do anything. I'm not familiar enough with Angular to fully understand why.
I was able to produce the required behaviour by overriding the ChangeDetectionStrategy
in my TestBed configuration.
TestBed.configureTestingModule({
imports: [],
declarations: [TestComponent],
providers: []
})
.overrideComponent(TestComponent, {
set: { changeDetection: ChangeDetectionStrategy.Default }
})
.compileComponents();
Still running on this to this day...
I personally like the overriding ChangeDetectionStrategy
solution as it's a one time thing on TestBed setup, but I understand this kind of intrusive solution isn't ideal.
TestBed.configureTestingModule({
imports: [],
declarations: [TestComponent],
providers: []
})
.overrideComponent(TestComponent, {
set: { changeDetection: ChangeDetectionStrategy.Default }
})
.compileComponents();
There's the "ChangeDetectorRef" solution which I've seen being used on the Component class itself with "changeDetector.markForCheck()" and that is not a good way as your component should not have to adapt to testing, but you can still use this solution, without messing with the actual component, by calling instead of the normal "detectChanges()", as presented here
const cdr = debugEl.injector.get<ChangeDetectorRef>(ChangeDetectorRef as any);
cdr.detectChanges();
And finally there's the simplest solution, at least in my head, and which, curiously, I haven't found any mentions to it.
So, you already probably know you can (or end up having to) create a host component to wrap the one you're testing, a lot of blogs, for example, out there showcase the usage of a @ViewChild(ComponentUnderTestComponent)
approach which would be perfect if jasmine could actually perceive a change in the child component, but, as it looks like, it doesn't and we are stuck with the normal intuitive approach of just listing the inputs in the host and binding them directly in the template of the testing component, like this:
@Component({
template: `<component-tag [(ngModel)]="val" [someProperty]="flag"></component-tag>`
})
class HostComponent {
val: number;
flag: boolean = false;
}
with that, now you can actually change the value of HostComponent.someProperty and then call detectChanges() and jasmine will perfectly do what it's supposed to and update the DOM with the change:
fixture.componentInstance.readonly = true;
fixture.detectChanges();
Now, if your component goes ahead and have dozens of input attributes, then I guess this isn't really viable, but anyway, I thought I'd throw it out there, enjoy
In my case due to async loading I needed to use fixture.whenStable not just fixture.detectChanges e.g.
it('test description', async(async () => {
await fixture.whenStable();
}));
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With