Как написать мраморный тест для этого пользовательского оператора RxJS, используемого в redux-observalbe Epic

Question

Мне нужно написать мраморный тест для моего пользовательского оператора, используемого в этом loadEpic эпично - это помогает мне избежать проблем, INITIALiZE иногда отправляется поздно, и я получаю LOAD_FAILURE:

loadEpic: Epic<ExamManagementAction, ExamManagementAction, RootState> = (
    action$,
    state$
  ) =>
    action$.pipe(
      filter(isActionOf(load)),
      waitFor(state$),
      switchMap(() =>
        this.load(state$).pipe(
          map(loadSuccess),
          catchError(error => of(loadFailure({ error })))
        )
      )
    );

и вот как я написал свой waitFor оператор, который отлично работает:

const waitFor = <T>(
  state$: Observable<RootState>
): OperatorFunction<T, T> => source$ =>
  source$.pipe(
    switchMap(value =>
      state$.pipe(
        filter(state => state.navigation.initialized),
        take(1),
        mapTo(value)
      )
    )
  );

Вы можете помочь мне написать этот тест с помощью rxjs-marbles/jestили какой-либо подобный подход? большое спасибо!

Answer 1

Вы описываете три потока событий:

1. состояния (имитируйте их простыми предметами)
2. действия (опять же, вы можете использовать любое значение JS в качестве имитации)
3. отфильтрованные действия (тот же объект, что и в 2)

Затем вы ожидаете, что ваш оператор преобразует 2 в 3 с помощью сопоставителя toBeObservable. Вот и все.

  it('should reject given values until navigation is initialized', () => {
    const state$ = hot('   -i--u--u-i--  ', {u: {navigation: {initialized: false}}, i: {navigation: {initialized: true}}});
    const action$ = hot('  v----v--v---  ', {v: load});
    const expect$ = cold(' -v-------v--  ', {v: load});

    expect(action$.pipe(waitFor(state$))).toBeObservable(expect$);
  });

Обратите внимание, как я отформатировал свой код так, чтобы один поток описывался под другим. Это действительно помогает с длинными последовательностями событий.

Вы также можете написать отдельные спецификации для крайних случаев. Это зависит от того, какое поведение вы хотите протестировать.