It is necessary to adjust your ngOnDestroy method in the following manner :

ngOnDestroy() {
  if ( this.routeSubscription)
    this.routeSubscription.unsubscribe();
}

I found that the issue was resolved by destroying the component after every test. You may want to consider incorporating this into your describe function:

afterEach(() => {
  fixture.destroy();
})

I find myself facing a situation where I need to test a function in my component independently of the component's context.

This is the approach that proved successful for me:

afterEach(() => {
  spyOn(component, 'ngOnDestroy').and.callFake(() => { });
  fixture.destroy();
});

You should include the following code snippet in your TestBed.configureTestingModule:

teardown: { destroyAfterEach: false },

By adding this line, your configuration will appear as follows:

beforeEach(async () => {
        await TestBed.configureTestingModule({
            declarations: [<Your component here>],
            imports: [<Your imports here>],
            providers: [<Your providers here>],
            teardown: { destroyAfterEach: false },
        }).compileComponents();
    });

My experience was somewhat similar, with a few differences that could be useful for others. During my unit testing using Jasmine/Karma, I encountered the following error:

'ERROR: 'Error during cleanup of component','

After some investigation, I realized this issue stemmed from not handling my observables correctly, specifically lacking an error function. The solution was to include an error function like so:

this.entityService.subscribe((items) => {
      // Do some work
},
error => {
    this.errorEventBus.throw(error);
});

In continuation of the answer provided by @David Brown, I found success with the following code snippet.

      .subscribe(res => {
          ...
        },
        error => Observable.throw(error)
      )

According to the insights shared by @randomPoison, the error arises when the component utilizing unsubscribe is not initialized. To tackle this issue in the spec file of the corresponding component, executing fixture.detectChanges() proves to be a viable solution.

In situations where we are working with a FooComponent that generates BarComponent, and the latter employs unsubscribe within its ngOnDestroy, it is crucial to ensure proper mocking is implemented.

An alternative method for handling subscription cleanup that is more declarative and less prone to these issues is recommended. Below is an illustration:

export class BazComponent implements OnInit, OnDestroy {
  private unsubscribe$ = new Subject();

  ngOnInit(): void {
    someObservable$
      .pipe(takeUntil(this.unsubscribe$))
      .subscribe(...);
  }

  ngOnDestroy(): void {
    this.unsubscribe$.next();
    this.unsubscribe$.complete();
  }
}

For further details on this approach, refer to this resource

To resolve this issue, there are two steps that need to be taken.

Step 1: Insert fixture.detectChanges(); within the beforeEach() function.
Step 2: Include the following code snippet to ensure the component is properly cleared.

afterEach(() => {
        fixture.destroy();
      });

My particular issue stemmed from a mistake in the template. The problem lied within the child component's ngDestroy function, which was failing to be destroyed due to my attempt at setting a readonly property. I recommend examining your child components to ensure they are being properly destroyed.

In order to resolve this issue, I made a simple adjustment within the ngOnDestroy method of my component. I enclosed both the store dispatch and unsubscribe functions in a try-catch block.

ngOnDestroy(): void {
 try {
  this.store.dispatch(new foo.Bar(this.testThing()));
  if(this.fooBarSubscription) {
   this.fooBarSubscription.unsubscribe();
  }
 } catch (error) {
   this.store.dispatch(new foo.Bar(this.testThing()));
  }
}

During my testing, I encountered a situation where I had a component with several @Input properties. To initialize one of the properties as an empty array, I assigned [] to component.xyz within the beforeEach block. This action inadvertently led to a problem in the testing process.

While setting one of the services variables to undefined, I encountered an error message. This particular variable contains the ID of the currently active entity being edited. Diving into the setter method, I realized that it was expecting a parent entity to be set... and since my tests did not include this step, it resulted in an error.

The code snippet causing the issue looked like this:

 ngOnDestroy(): void {
    this.subs.forEach(s => s.unsubscribe());
    this.xxxEditService.activeYYY = undefined; // The setter requires a parent entity to be set
 }

To resolve this issue, I added a mock entity in my test file:

providers: [
 {
   provide: xxxEditService,
   useValue: {
     parentEntity: {} as Parent,
     activeYYY: -1   // id
   }
}

TLDR: Errors were occurring during clean up due to non-valid presets, such as null or undefined references.

The reason for the problem was a simple human mistake.

In my specific situation, I overlooked adding the sendC method (which was a newly added method to ABCComponent) to the list of methods in the dependent spy component. To illustrate:

let abcComponent: jasmine.SpyObj<ABCComponent>
///
beforeEach(async () => {

    abcComponent = jasmine.createSpyObj('ABCComponent', [
      'sendA$',
      'sendB$',
      'sendC$' // I initially missed this and encountered the 'Error during cleanup of component' failure. Once I included it, the issue was resolved.
    ])

    await TestBed.configureTestingModule({
      declarations: [AComponent],
      providers: [
        AState,
        APipe,
        BPipe,
        
        { provide: ABCComponent, useValue: abcComponent },
        { provide: Router, useValue: routerSpy },
        { provide: NavigationService, useValue: navigationServiceSpy},
      ],
      imports: [ABCModule]
    })
      .compileComponents()
      abcComponent = TestBed.inject(ABCComponent) as jasmine.SpyObj<ABCComponent>
  })

By rectifying this oversight, not only did I fix my own issue but hopefully, it will help resolve similar problems for others too!👍