timbuckley / redux-saga-test-engine Goto Github PK

See #9 (comment)

After PR #16 is merged, I should update the README to show the new API.

• As API has expanded to more than one function, there should be a API section on the README.

As you may have heard in the news, DNAinfo has been shut down, and so the github org hosting this library may also be closed soon.

Accordingly I am getting this repo moved to my github account (timbuckley/redux-saga-test-engine). This should not affect you if you just want to use the library on npm (ie npm i --save-dev redux-saga-test-engine), but will if you depend on the git repo directly (which is not recommended anyway).

Just wanted to make all interested parties aware of this change. :-)

Redux Saga will throw rejected promise values into the generator which will cause jump to the catch block in a try catch. Currently, we cannot test this catch block without some very hacky code in the sagaEnv.

function* mySaga() {
  try {
    yield call(doPromiseThing);
    yield put(alert, 'All good!')
  } catch (e) {
     yield put(alert, e);
  }
}

If you were to test this saga with a sagaEnv where the doPromiseThing returns a rejected promise, it would not throw the rejected value into the saga. It would call gen.next with the promise, and then continue onto the All good! alert call.

https://github.com/DNAinfo/redux-saga-test-engine/blob/64b3732eb1192df603378ccae603a21e2c7fb1b9/src/index.js#L85

Per CircleCI,

Service alert: Your project references CircleCI 1.0 or it has no configuration. CircleCI 1.0 and projects without configuration files are no longer supported. You must update your project to use CircleCI 2.0 configuration to continue.

https://circleci.com/sunset1-0/

I wanted to give your library a try in a react-native (0.45) project, but as soon as I import something from it, the test fails with the following error:

Couldn't find preset "env" relative to directory "[snip]/app/node_modules/redux-saga-test-engine"

There doesn't seem to be any documented requirements regarding build configuration from your side, so I'm not sure if I'm doing something wrong or if this is an error in the library setup.

Please let me know if you need any more input.

If a user messes up their nested array in collectPuts, the error message provided is not that helpful as it's written to explain incorrect use of types, but not why a specific assertion failed:

It would be better if a secondary assertion for the nested array was added to explicitly explain why the array approach failed with an error message of something like:

"The nested arrays must have exactly two arguments".

I'm trying to upgrade to 2.0.3 so that I can update tests with specific params using throwError, but it doesn't seem to be installing the correct code. The built code that is downloaded appears to be an older version of the library, because I can see the old code for throwing errors

    if (_throwError) {
      genResult = gen.throw('ERROR');
    } else {
      genResult = gen.next(nextVal);
    }

that code should lookup the value in nextVal

    if (throwError) {
      genResult = gen.throw(nextVal[throwErrorKey] || 'ERROR')
    } else {
      genResult = gen.next(nextVal)
    }

Referencing #26.

I am not well versed in making a package babelified, and my last attempt (#27) seems not to have worked. I can figure it out but it will take me time to read the docs about it. If anyone wants to help correct this, I would be much obliged!

In your comparison with other testing libs you only compare the unit type approach of redux-saga-test-plan. By now it also has integration like behaviour:

it('handles reducers', () => {
  return expectSaga(saga)
    .withReducer(dogReducer)

    .put({ type: AGE_BEFORE, payload: 11 })
    .put({ type: AGE_AFTER, payload: 12 })

    .dispatch({ type: HAVE_BIRTHDAY })

    .run();
});

I will try both and let you know my findings.

Inspired by https://github.com/jfairbank/redux-saga-test-plan :-)

redux-saga-test-plan has changed pretty dramatically since the README was written and since this discussion with the author. Worth a more thorough comparison :-)

Currently an Env mapping is missing a value for... error will be thrown when a mapping specifies undefined as its return value, ie

[call(shouldReturnUndefined), undefined]

due to the check on line 164 of core.js:

var nextValFound = nextVal !== undefined;

I believe undefined is a valid return value, so this throw condition seems to be in error. The absence of a return value should instead be caught by isNestedArray, which confirms the array has a length of 2.

My suggested fix would be to remove line 164 (happy to do a PR!), but raising an issue to confirm there's not some other reasoning behind this assertion.

To make this library useable in various node versions, the ES6 src/ code should be compiled to ES5 into a build/ directory, rather than deploying the ES6 code directly as it currently does.

• A build process should be set up (using babel, etc).
• This build version should go to NPM.

I don't think this should affect versioning but I'm open to other opinions.

Just diving into testing sagas so bear with me if this is obvious.

My understanding is collectPuts shouldn't need env mappings for PUTS or am I just sadly mistaken?

Env Mapping is missing a value for {
      "@@redux-saga/IO": true,
      "combinator": false,
      "type": "PUT",
      "payload": {
        "action": {
          "type": "authorization/UPDATE_TOKEN",
          "payload": "mockAuthorizationToken"
        }
      }
    }

My saga is just a select() and yields put(). Something like:

export default function* onSuccess(response) {
    const previousToken = yield select(selectAuthorizationToken);

    yield put(updateToken(...))

    return response; // response interceptor stuff requires this
}

It's a little unclear about what the expected behavior of yield* should be handled in a testing paradigm.

We're unable to use the new features in the lib, because it hasn't been published to npm

A user may reasonably want to detect whether a select or call has been triggered as well.

Outside opinions on this would be helpful. 😃

It won't provide a performance benefit, but will allow the API to handle more things thrown at it.

Sometimes an array of PUT effects may be yielded. The test engine should treat it identically to a single PUT in terms of the the final returned puts array.

Example

yield [
  put(actionOne()),
  put(actionTwo())
]

Also, a single array of puts, selects, calls, etc may be yielded at once. Must consider how best to handle this event.

yield [
  put(actionOne()),
  select(something),
  call(somethingElse),
  put(actionTwo())
]