{"action":"opened","issue":{"url":"https://api.github.com/repos/yelouafi/redux-saga/issues/59","labels_url":"https://api.github.com/repos/yelouafi/redux-saga/issues/59/labels{/name}","comments_url":"https://api.github.com/repos/yelouafi/redux-saga/issues/59/comments","events_url":"https://api.github.com/repos/yelouafi/redux-saga/issues/59/events","html_url":"https://github.com/yelouafi/redux-saga/issues/59","id":128615561,"number":59,"title":"Create a test-utils library with raceResult()","user":{"login":"mjrussell","id":1641895,"avatar_url":"https://avatars.githubusercontent.com/u/1641895?v=3","gravatar_id":"","url":"https://api.github.com/users/mjrussell","html_url":"https://github.com/mjrussell","followers_url":"https://api.github.com/users/mjrussell/followers","following_url":"https://api.github.com/users/mjrussell/following{/other_user}","gists_url":"https://api.github.com/users/mjrussell/gists{/gist_id}","starred_url":"https://api.github.com/users/mjrussell/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mjrussell/subscriptions","organizations_url":"https://api.github.com/users/mjrussell/orgs","repos_url":"https://api.github.com/users/mjrussell/repos","events_url":"https://api.github.com/users/mjrussell/events{/privacy}","received_events_url":"https://api.github.com/users/mjrussell/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-01-25T19:21:23Z","updated_at":"2016-01-25T19:21:23Z","closed_at":null,"body":"I've recently been writing some tests for a race condition and Im really impressed with how easy it is to test. There's one thing that bothers me a little bit which is how the tester needs to know a bit about the implementation of race.\r\n\r\nLets say we have the following (inside some loop with an interval variable):\r\n```js\r\n const { stop, update } = yield race({\r\n    delay: call(delay, interval),\r\n    update: take('UPDATE'),\r\n    stop: take('STOP'),\r\n  })\r\n\r\n  if (stop) {\r\n    break;\r\n  } else if (update) {\r\n    interval = update.payload.interval;\r\n  }\r\n      \r\n```\r\n\r\nI can do a test like:\r\n```js\r\n   let next = generator.next()\r\n    expect(next.value).to.deep.equal(race({\r\n      delay: call(delay, 100),\r\n      update: take('UPDATE'),\r\n      stop: take('STOP'),\r\n    }))\r\n\r\n    // Assume update wins\r\n    next = generator.next({ update: { payload: { interval: 50 } }, start: null, delay: null })\r\n    // Test something on the update\r\n```\r\n\r\nThis is actually pretty good, but it seems like I have to know something about the internals of race. I wonder if it might make more sense to include a `raceResult` testUtility that allows you to abstract this knowledge away and if in the future the internals of race change, it would be transparent.\r\n\r\nId imagine something like:\r\n````js\r\ngenerate.next(raceResult({\r\n   update: { payload: { interval: 100 }\r\n})\r\n```\r\nor even `generate.next(raceResult('update', { payload: { interval: 100 }))` and have it handle the unpacking to null.\r\n\r\nDo you think this would be something useful? If so I could swing a PR together. I could envision several testing utilities for the spec mode, maybe there is one for handling the tasks which have been popping up in other issues.\r\n"}}