refactor mapreduce tests with async/await

[emilygilberts]

tests/unit

• rewrote the unit tests for mapreduce.js-upsert using async/await
  (left the mapreduce.js-utils tests as they are, because they are more readable & straightforward with the current syntax)

tests/mapreduce (in process)

• started with some ES6 refactoring of the tests by replacing var with const/let
• rewrote promise chains to async/await
• used arrow functions
• rewrote mocha chai should syntax: (before: should.become to should.deep.equal for objects or should.be.true for boolean)
• replaced .toString() with template literals (except on view map function declarations)

tests/mapreduce/test.mapreduce.js
in test Query result should include _conflicts and Views should include conflicts :

• replaced the use of testUtils.fin() with try/finally block
• replaced the use of promisify with simply awaiting the replication - so that testUtils.promisify(remote, db.replicate); becomes await db.replicate.from(remote);

in test Test view querying with custom reduce function:

• in custom reduce function: replaced nested unrolling of values with values.flat()
• remoed unneccesary line pulling out keyId[0]
• ? can the comment //const id = keyId[1]; be deleted?

[janl]

this looks good overall, I’m just wondering if it would make sense to DRY out the get and put functions a little bit, it’s three lines each when the only difference is the what the promise resolves with.

Spitballing here:

instead of

   const res = await upsert(
      {
        get: function () {
          return Promise.reject({ status: 404 });
        },
        put: function () {
          return Promise.resolve({ rev: 'abc' });
        },
      },
      'foo',
      function () {
        return { difference: "something" };
      },
    );

function makeFun (action, value) {
  return function() { return Promise[action](value) };
}

// [...]

    const res = await upsert(
      {
        get: makeFun('resolve', {status: 404}),
        put: makeFun('reject', { rev: 'abc' }),
      },
      'foo',
      function () { return { difference: "something" };
      },
    );

Might be too fancy, feel free to shoot me down :)

[janl]

just a style nit, but I’d be okay with having the opening curlies start with the method: upsert({ to save a mostly empty line

[emilygilberts]

@janl hmm how about using arrow functions for the functions in get and put? I think it could look neat/be readable cause they are all one liners.

[emilygilberts]

UPDATE: ahhh my local CouchDB wasn't properly connected ... nvm :)

I'm running the tests locally with TYPE=mapreduce npm run test-node. Any idea why they all pass for test.mapreduce.js-persisted, but for test.mapreduce.js-temp the first test executed jumps out with a timeout error?

[emilygilberts]

hmm wondering - in some tests we had promise chains that did multiple queries that returned res to then be evaluated with should expressions. I always reassigned res to keep the same names as before, but I'm guessing it would be better style to use const and res, res2,... ?

[emilygilberts]

Actually, could it be a problem in some setups that I changes the map function to an arrow function? It will be converted to a string in the createView function:

const storableViewObj = {
          map: `${viewObj.map}`
        };

[janl]

should be fine in tests, but lets leave them in their CouchDB-canonical traditional function form