Ideas on a testing focussed code transform

Isiah Meadows isiahmeadows at gmail.com
Sat Dec 16 05:14:07 UTC 2017


You're describing a variant of the interpreter pattern. I've used similar
in task scheduling contexts, and the key drawback is you no longer have
useful stack traces.

I haven't done any formal research on the approach, though. I will caution
you that async functions are already widely used enough (particularly in
Node) they're unlikely to go anywhere beyond something drastic.

On Sat, Dec 16, 2017, 00:07 Pranay Prakash <pranay.gp at gmail.com> wrote:

> 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
> scenarios.
>
> 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)?
>
> Cheers,
> Pranay
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171216/1369fb2f/attachment-0001.html>


More information about the es-discuss mailing list