I'll try and make this an easy ask,
If i have a selector that takes in a parameter and i override that selector, the overrided selector is never called and the mockstore continues to call the real selector implementation.
ex i have a selector called
export const getHeroesById = id =>
createSelector(
getAllHeroes,
heroes => { return heroes.filter( hero => hero.id ===id);}
);
and in my test I say
const testHero = Hero[] = [
{id; '1', name: 'hero 1'},
];
....
mockStore.overrideSelector(fromReducer.getHeroesById('1'), testHero);
I expect the overridenSelector to return me testHero whenever it is called with a string of 1 but currently it won't return anything,
The only way around this is to mock the selector for getAllHeroes and have data that matches the filter condition.
Is this expected behavior, am i missing something simple, i have yet to find documentation or an example on how to achieve what i'm asking (or should we be just mocking the base selectors and allowing the other selectors that filter or take in parameters to run un mocked, if that is the case how do we ease the burden of testing if our selectors have like 3 or 4 of these conditions?)
Check your imports. It was the case for me as one of my import was relative and another one absolute.
are you talking about your reducer imports? or which imports are you referring to
AFAIK it isn't possible to mock a selector that takes a parameter like this.
Currently, we mock the instance of the selector, by creating a factory selector you end up with a new instance every time you create the selector.
The only way I see to make it work now, is to create the instance somewhere (e.g. in the component) and mock this instance. Or to mock the selectors it has as input, the way you mentioned.
Closing as wont fix
@timdeschryver
The only way I see to make it work now, is to create the instance somewhere (e.g. in the component) and mock this instance
How can I do that?
Background story:
I'm working on an application, where we use factory selectors almost everywhere. Is this considered to be a bad practice?
The app consists of widgets, several instances of the same components using several instances of the same selectors. The main reason behind the different instances of the selectors is to optimize and leverage the onPush change detection.