Tests should allow us to configure the store

[johnstill]

This is a...

• [ x] feature request

What toolchain are you using for transpilation/bundling?

• [ x] @angular/cli

I'm using angular-redux with immutable.js and I would like for there to be some mechanism by which to configure the store for a test run.

First, I cannot use NgReduxTestingModule. I get errors similar to "state.getIn" is not a function. As a workaround I'm doing this in each describe:

import {fromJS} from 'immutable';
// ...
  beforeEach(async(() => {
    mockReduxInst = MockNgRedux.getInstance();
    const _old = mockReduxInst.getState;
    const _wrapped = () => fromJS(_old());
    mockReduxInst.getState = _wrapped;

    TestBed
      .configureTestingModule({
        declarations: [/* ... */],
        imports: [/* ... */],
        providers: [
          {provide: NgRedux, useValue: mockReduxInst},
          /* ... */
        ],
      })
      .compileComponents();
  }));

But I think it would be cleaner if I could just provide the initial state for the test object.

Secondly, there are some scenarios where I would like to test complex interactions that rely on data in a lot of different parts of the store, and currently there doesn't appear to be any way to do that. If I understand correctly, the selector stubs will only mock out calls to select, correct - so any transformations of state that rely on NgRedux.getState() or transforming selectors that pull data from multiple places cannot be mocked this way? I'd love some clarity on this point - how do I efficiently seed a the store with a lot of data for a test case?

Thank you for your time!

[johnstill]

Actually I've realized I can just

mockReduxInst.getState = () => complexInitialState;

at the top of any test that requires complex initial state, so that mitigates my second question somewhat in practice. I maintain this functionality would be better as a supported feature than as a monkey-patch.

[e-schultz]

I'll take a look into this, seems like there are potentially two things here.

• one - ability / desire to provide an initial state during TestBed config
• also seems like possibly a bug where stubs are not handling immutable properly

[johnstill]

For the second point, this line is the culprit - any store built on an object with methods (beyond those on {}, of course) will eventually fail when one of those methods is called - such as, e.g., getIn on an immutable.js Map.

If you can provide a way for users to set this function through the public API (short of the unofficial monkey patching I did above) I think that would be satisfactory.