feat(signals): add unprotected testing helper

[markostanimirovic]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/ngrx/platform/blob/main/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Documentation has been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Closes #4540

What is the new behavior?

The new testing plugin is added with unprotected helper:

import { unprotected } from '@ngrx/signals/testing';

const CounterStore = signalStore(
  { providedIn: 'root' },
  withState({ count: 0 }),
  withComputed(({ count }) => ({
    doubleCount: computed(() => count() * 2),
  })),
);

it('works', () => {
  const store = TestBed.inject(CounterStore);
  patchState(unprotected(store), { count: 1 });

  expect(store.doubleCount()).toBe(2);
});

Does this PR introduce a breaking change?

[ ] Yes
[x] No

[netlify]

✅ Deploy Preview for ngrx-io ready!

Name	Link
🔨 Latest commit	406c062
🔍 Latest deploy log	https://app.netlify.com/sites/ngrx-io/deploys/67dc8cd4e5908d00084f7745
😎 Deploy Preview	https://deploy-preview-4725--ngrx-io.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[rainerhahnekamp]

I went through the discussion on the issue and just wanted to share a thought. I feel there’s a bit of a risk that unprotected might be used in unintended ways in application code — something we might be able to reduce by adjusting the design so that unprotected is only accessible via a TestBed context.

There are two areas that could lead to accidental usage:

• AI-assisted coding tools may suggest unprotected in application code.
• IDEs often auto-import from testing, and it’s easy to overlook where the import is coming from.

One idea might be to use something like injectedUnprotectedStore, or even take a similar approach to Angular’s routing and HTTP testing setup by providing a fake service:

TestBed.configureTestingModule({ provideNgRxTesting() });
const { unprotected } = TestBed.inject(NgRxTesting);

I know this could still be misused, but the design would more clearly indicate that it’s intended for testing.

@markostanimirovic, @timdeschryver

[timdeschryver]

Nice! 💪

[timdeschryver]

Sorry @rainerhahnekamp , I missed your comment.

I get your point, on the other hand, I like the simplicity of the unprotected in this PR.
Because we cannot guarantee it will be misused, I'm fine with the simplicity.
This is better than manually casting a protected state in a test, or in production code.

I hope teams will review their code to catch these misuses, and/or create a rule that testing imports are forbidden in "normal" *.ts files.

[jahusa02]

Its added to the official Docs (19.0.1). Tried to use it but ofc getting an error 😅

https://ngrx.io/guide/signals/signal-store/testing#unprotected

just noticed because it ofc doesn't find the package

[EinfachHans]

Just read the docs and wondered why it is not working for me 😃

Any plans about when the next release including this will happen?

[markostanimirovic]

The new minor release will be published in the next 1-2 weeks. We're waiting for a few more features to land.