Ideas on a testing focussed code transform

Pranay Prakash at
Sat Dec 16 05:07:06 UTC 2017

Hey all,

I was just reading the docs for `redux-saga` where I encountered a nice
design pattern for a saga which is (correct me if I'm wrong) a
regular javascript generator function that yields the intent to call a
function (instead of actually calling a function) until it goes through all
the steps. If that doesn't make sense, consider this simple function:

async function findFriends() {
  const myId = getMyID();
  const myUser = await fetchUser(myId);
  return myUser.friends;

instead of actually making the function calls needed, we can instead have a
function that does something like this:

function* findFriends() {
  const myId = yield { fn: getMyID };
  const myUser = yield { fn: fetchUser, args: [myId] };
  return myUser.friends;

This is a pure generator function that doesn't actually do anything, but
has all the necessary information to recreate the original function[1] (or
have a library "trampoline" through the function and make all the necessary
calls for you)

A HUGE plus of the second version of the function is that it's *easily*
testable (unlike the first one). Pure functions are easier to test. Testing
this is simply a matter of calling `.next()`, getting the "intent", making
sure the right intent was yielded (good enough for unit testing) and
calling `.next()` again with the "mock" value, you want to return and
continue to test.

An observation to make here is that you can transform the original version
of this code (easy, normal code to write) to the latter (easy code to
test). So, what about having some sort of babel transform perhaps that can
convert the first to the second but only in the context of unit tests. You
write code the normal way as you would for your application and don't worry
about test suite implementation details (mocking/dependency
injection/etc.), and when you want to test, simply import your function
(which gets converted to a generator) and step through it to test different

I personally think this is a super clean way to do testing since the tests
never interfere with how you actually write the code AND you don't have to
explicitly mock.

Does anyone have thoughts on this / prior research (or knows about an
existing implementation of this)?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list