beforeEach with waitForAsync fails when trying to compile a component about query HOT 3 CLOSED

I've revisited this and I can't remember why, but I've misunderstood why my tests fail.

It's still because of the waitForAll in beforeEach, but it happens when multiple tests run a mutation, and mutation.result$ is subscribed to:

@Component({ template: `{{ mutation.result$ | async | json }}` })
class AppComponent implements OnInit {
  mutation = inject(UseMutation)(() => of('hello world'));

  ngOnInit() {
    this.mutation.mutate('id')
  }
}

beforeEach(waitForAsync(() => {
  TestBed.configureTestingModule({declarations: [AppComponent] });
  TestBed.compileComponents();
}));

it('should work 1', () => {
  const component = TestBed.createComponent(AppComponent);
  component.detectChanges()
});

it('should work 2', () => {
  const component = TestBed.createComponent(AppComponent);
  component.detectChanges()
});

Which is why I think it might be similar to #82

from query.

@cuddlecake did you found a fix in the meantime?

So what is happening here exactly? From what i can see is, that @tanstack/query is caching/memoizing the mutation under the hood and is returning the same instance you had in the should work 1 test. Since the result$ observable is saved on the MutationObserver (L44) it gets also saved/memoized/cached by @tanstack/query under the hood.

The logical reason then would be to clear all caches (with QueryClientService.clear()) and tearing down the entire TestBed to get a clean new MutationProvider for every test case. But when you run your Angular Test cases with ng test (the Angular CLI) then you dont need to add the waitForAsync and .compileComponents() to beforeEach(...), this is just boilerplate Angular generated for you so you could run your tests with the jest runner (or any other) for example. I would remove the waitForAsync and .compileComponents() boilerplate, it runs fine without it, but only if you dont need to do a custom buildup for your app.

BTW, i tried to apply the "fix" i used in #82 by adding shareReplay(1) which confirmed that its kinda similiar, if not the same issue. But this shouldnt be used as a "fix" since everytime you'd rebuild the TestBed for every test case, you would also chain a new shareReplay(1) to the result$ operator (looking like this then: result$.shareReplay(1).shareReplay(1).... and so on). This would work, but in the long run maybe slow down you pipe.

from query.

I didn't find or search for a fix, since I couldn't introduce this library at work yet.
Also, waitForAsync and .compileComponents() is difficult to omit, since we make heavy use of ngneat/spectator here, and it involves both of these functions

And I don't feel like explaining the nuances of shareReplay as a workaround to my colleagues 😄 I might try again at some point, to introduce this lib at work, but not allow usage of useMutation.

from query.