Jits

@rainerhahnekamp — I do think having a `mockSignalStore` high level helper is a very good first step (and probably more impactful to the community at large). My particular need could...

Aside: @rainerhahnekamp — you may have intended to use a different link for your point (2) above?

Hi @rainerhahnekamp, I think your proposal works very well for simple cases (which may be the majority?). I guess it has the same implications as managing any manual mocks —...

This is a great idea @rainerhahnekamp. Would it be too far-fetched to suggest that this should be the _default_ behaviour? The fact that a store can be patched from anywhere...

@rainerhahnekamp — makes sense. I guess it comes down to what the _default_ usage is expected to be; your config option could still be used to turn on `patchState` access...

Ah, that's good to know! Not a big deal — could be covered by documentation (as a feature + gotcha). Another thought: could log a warning in console when in...

> In the same way as you do for any other service using `TestBed`: > > ```ts > TestBed.configureTestingModule({ > providers: [MyStore, { provide: MyService, useValue: { doSomething: jest.fn() }...

Hi @rainerhahnekamp — ahh yes, good spot, thanks. I missed that aspect. (I'll update my comment to reflect this). I don't suppose you have a good way to _build_ a...

@rainerhahnekamp — that sounds great! (I'll continue with additional thoughts there)

@rainerhahnekamp — may I suggest using this utility from `ts-fest`: https://github.com/sindresorhus/type-fest/blob/main/source/readonly-deep.d.ts