Accordion throws ExpressionChangedAfterItHasBeenCheckedError in Jest unit tests if *clrIfExpanded is set

[JeTmAn1981]

So I'm writing unit tests for a component that uses a Clarity Accordion. It was driving me nuts because I could not for the life of me figure out why a ExpressionChangedAfterItHasBeenCheckedError was being thrown by the tests. It doesn't occur when running the application, and there's nothing obvious in the component itself to trigger that error (not doing anything in ngAfterViewInit or anything like that).

After literal days of debugging I finally realize that *clrIfExpanded is the culprit. Somewhere along the line it must be making changes to the view late in the testing process.

The question is, what do I do about this? I need to write tests against these components. But, I don't know how to avoid this error. I can't get even get a test that creates the component to pass with this in place.

[hippee-lee]

Hi @JeTmAn1981 - a couple of questions to help me help you.

1. Do you have code that you can share (either with stackblitz or a small repo) that demonstrates the issue you are encountering?
2. Have you looked at how we test the accordion components themselves in the *.spec.ts files here? All of the accordion components are covered with unit tests and we don't have an issue with EHCAIWC.
3. Finally, is there a reason you are testing the clarity components? Generally, all clarity components ship with unit tests that include coverage for most of the common use cases and features. Apps shouldn't need to write unit tests for clarity components and if there is a feature or use case missing in our current specs let us know so we can address it.

[JeTmAn1981]

I took a look at the accordion tests but I'm not sure where the tests for the *clrIfExpanded directive are.

I am not testing the Clarity components. I'm trying to test my component which uses a Clarity accordion, which is making the tests fail.

I'm having trouble with stackblitz so I'll just paste some code here. Here is the component I want to test:

Template:

<div>
  <clr-accordion [clrAccordionMultiPanel]="true">
    <clr-accordion-panel [clrAccordionPanelOpen]="true">
      <clr-accordion-title class="overview-header">
        
      </clr-accordion-title>
      <clr-accordion-content *clrIfExpanded>

        <div class="clr-row comparison-row date-row">
          <div class="clr-col-3">
            <h5>Statement Date</h5>
          </div>
          <date-field 
              class="clr-col-3"
             [value]="2001"></date-field>

        </div>
   </div>
      </clr-accordion-content>
    </clr-accordion-panel>
  </clr-accordion>
</div>

Component:

@Component({
 selector: 'comparison-overview',
 templateUrl: './comparison-overview.component.html',
 styleUrls: ['./comparison-overview.component.scss']
})
export class ComparisonOverviewComponent implements OnInit, OnDestroy {
      
 ngOnInit(): void {
 }
  ngOnDestroy(): void {
  }
}

I've slimmed this down to just an accordion and a single child component. The original thing had a lot more stuff in it but as I've been troubleshooting I've cut things out to rule out problems. In addition, the date-field component there (a custom component of mine) normally has a lot more Inputs but the EHCAIWC errors were related to the Input fields so I cut those out one by one to see if any particular one was the problem.

I should note that my tests do pass if I remove all Input fields from the date-field component, but that component is so simple at this point I do not think it's actually the problem. The issue goes away as soon as I remove the *clrIfExpanded directive from clr-accordion-content.

Here is my date-field component currently:

Template:

test

Component:

@Component({
  selector: 'date-field',
  templateUrl: './date-field.component.html',
  styleUrls: ['./date-field.component.scss', '../form-field.component.scss']
})
export class DateFieldComponent  implements OnInit {
  constructor() {
  }
  
  ngOnInit(): void {
    
  }
  
  
  private _value: any;

  @Input()
  set value(val: any){
      this._value = val;  
  }
  get value()  {
      return this._value;
  }


}

And my test is just this:

const mockAuth = {
  user$: of({
      name: 'Tom Cruise'
  }),
  logout: jest.fn()
}
let mockBillDataService: MockBillDataService;
let mockBillEditorService: MockBillEditorService;
let mockEnvService: MockEnvService = new MockEnvService();

const mockFormGroups = new FormGroup({
  billDetailForm: new FormControl(),
  billOverviewForm: new FormGroup({statementDate: new FormControl()})
});

const formGroupDirective = new FormGroupDirective([], []);
formGroupDirective.form = mockFormGroups;


describe('ComparisonOverviewComponent', () => {
  let component: ComparisonOverviewComponent;
  let fixture: ComponentFixture<ComparisonOverviewComponent>;

  
  beforeEach(async(() => {
    mockBillDataService = new MockBillDataService();
    mockBillEditorService = new MockBillEditorService();
    mockEnvService = new MockEnvService();

    TestBed.configureTestingModule({
      declarations: [ ComparisonOverviewComponent ],
      imports: [
     ClarityModule, ClrAccordionModule, DateFieldModule
     ,HttpClientModule,
     NoopAnimationsModule
      ],
      providers: [
     {provide: BillDataService, useValue: mockBillDataService},
     {provide: FormBuilder, useClass: FormBuilder},
     {provide: HttpService, useClass: HttpService},
     {provide: HttpClient, useClass: HttpClient},
     {provide: SnEnvService, useValue: mockEnvService},
     {provide: ControlContainer, useValue: formGroupDirective}
    ]
    })
    .compileComponents();
  }));

  beforeEach(() => {
    fixture = TestBed.createComponent(ComparisonOverviewComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('should create', () => {
    expect(component).toBeTruthy();
  });
});

So....as I've been working on this I realize I can just remove *clrIfExpanded since I don't actually need lazy loading of my accordion content; I want the accordion to be open by default anyway, so it should load right away.

But the question remains....why was *clrIfExpanded causing this issue? Reading the description I do get a clue of why it might be causing EHCAIWC errors:

"A structural directive that optimizes the accordion by only creating the panel content node when its in the open state. The panel content node is removed from the DOM when closed."

It sounds like it's going to be altering the view at some point, so if it reads the accordion open property after the view has already begun being built, then alters it by adding content, it seems like that could trigger the EHCAIWC errors. But I don't really know what to do about it if I do need to use this in the future.

[hippee-lee]

*clrIfExpanded is just a specialized directive to handle that state. Think *ngIf but specific for @clr/angular things that expand. If you put an *ngIf on the template do you still get the EHCAIWC error?

If you can push a simple repo with the above code that runs I'm happy to investigate.