const someSelector = (props: string) => createSelector(
someRootSelector,
(state) => {
// some computation with state using props
}
);

store.select(someSelector('hello')).subscribe(...);


Here just using `overriderSelector` is not sufficient as it is resulting in undefined. Any recommendations on how to test this scenario?

Good to hear!

Awesome with the update!

I agree with the facades, and have used something similar in projects too. But seeing as you´d need/want to test those anyways, the mockStore becomes pretty valuable in things like integration tests.

I´d love to talk more testing if you´re free one day

Hi Poul,

Thank you for that. You are right about the selector functions itself should be tested in isolation. I have now updated the post with a selector test that uses projector to test in isolation.
It is nice with the mockStore compared to stubbing the whole store for every test. The benefits with using these facades is that you don’t need to deal with the mockStore at all, which I find eliminates the most boilerplate.

I got a question regarding the selectors.

You mention reducers as pure functions, but so are selectors?
in ngrx you can easily test selectors with the .projector() function.

In your example, you´re testing your class TodoListSelector, which is a facade / layer on top of the ngrx selectors. But you´re not really testing the selector itself.

Also, if you hadn´t seen, ngrx introduced the mockStore with version 7, so testing components / classes interacting with the store becomes a lot easier!

Nonetheless, nice reading about more Angular testing!