proposal: Hide Test internals. Expose a delegate object instead.

[jamestalmage]

We expose instances of Test to the user. It's the t in the following code:

test('title', t => {
  t.is(foo, bar);
});

That has all kinds of internal information on it, including

• assertCount
• planCount
• duration
• _timeStart
• planStack
• etc, etc, etc.

We are already looping over all the public methods and binding them to the test here so users can pass around methods without worrying about this bindings.

I suggest we copy those values (perhaps being a bit more careful to select only that which we truly want public), to a secondary object that we expose.

[sindresorhus]

👍 from me. @vdemedes ?

[vadimdemedes]

What if we just made them non-enumerable? So that we won't need to use this.options.assertCount instead of this.assertCount inside lib/test.js itself.

[jamestalmage]

We would not need to do that. We would create a different object, and put methods on it that were bound to the test instance test:

Test.prototype._createPublicAPI = function () {
  var api = {};
  var self = this;
  listOfPublicMethods.forEach(function (methodName) {
    api[methodName] = self[methodName].bind(self);
  });
};

Or we could use delegates.

The problem with non-enumerable is that they can still be clobbered. I am working on #25 (registering custom assertion methods) - and we don't want to have to force them to avoid our internals as they name their method.

[vadimdemedes]

Oh, I get it now. delegates usage would be really good, love this module.