`t.context` Functions

[schnittstabil]

I know, I can easily workaround this, but I don't know if there is a good reason for use-t-well to complain#L60-L71 about my use case:

test.beforeEach(t => {
    const tmp = tempfile();
    t.context = (...paths) => path.join(tmp, ...paths);
});

test(async t => {
    mkdirp.sync(t.context('src')); // <--- Unknown assertion method `context`

    // await fn(…);

    t.true(fs.lstatSync(t.context('dest')).isDirectory());
    t.true(fs.lstatSync(t.context('dest', 'src')).isDirectory());
});

NB: avajs/ava#106 (comment) and ava/readme.md:

By default t.context is an object but you can reassign it

[vadimdemedes]

By default t.context is an object but you can reassign it

We meant you can assign your own object. We did not predict that someone would assign t.context a function.

May I ask why are you making context a function? Do you have a real world example where it's useful?

[schnittstabil]

@vdemedes I want to simplify some cpy tests.
Calling path.join everywhere sucks, and make the code less readable, e.g.:

test.beforeEach(t => {
    t.context = tempfile();
});

test('cwd', async t => {
    fs.mkdirSync(t.context);
    fs.mkdirSync(path.join(t.context, 'cwd'));
    fs.writeFileSync(path.join(t.context, 'cwd', 'hello.js'), 'console.log("hello");');

    await fn(['hello.js'], 'dest', {cwd: path.join(t.context, 'cwd')});

    t.is(fs.readFileSync(path.join(t.context, 'cwd', 'hello.js'), 'utf8'), fs.readFileSync(path.join(t.context, 'cwd', 'dest', 'hello.js'), 'utf8'));
});

vs:

test.beforeEach(t => {
    const tmp = tempfile();
    t.context = (...paths) => path.join(tmp, ...paths);
});

test('cwd', async t => {
    fs.mkdirSync(t.context());
    fs.mkdirSync(t.context('cwd'));
    fs.writeFileSync(t.context('cwd', 'hello.js'), 'console.log("hello");');

    await fn(['hello.js'], 'dest', {cwd: t.context('cwd')});

    t.is(fs.readFileSync(t.context('cwd', 'hello.js'), 'utf8'), fs.readFileSync(t.context('cwd', 'dest', 'hello.js'), 'utf8'));
});

Clearly, I can do t.context.tmp = (...paths) => … or similar – I'm just curious if this is on purpose and what the reasons were.

[vadimdemedes]

Having t.context as a function is not logical to me. In JS land context is an object in most cases. If you absolutely have to go this way, I'd at least make it a property of t.context: t.context.tmpPath = () => ....

If you are interested, I'd simply use join, because it's basically the same:

const {join} = require('path');

test.beforeEach(t => {
  t.context.path = tempfile();
});

test('something', t => {
  const {path} = t.context;

  fs.mkdirSync(path);
  fs.mkdirSync(join(path, 'cwd'));
  fs.mkdirSync(join(path, 'cwd', 'hello.js'));
});

vs

test.beforeEach(t => {
    const tmp = tempfile();
    t.context.tmpPath = (...paths) => path.join(tmp, ...paths);
});

test('something', t => {
  const {tmpPath} = t.context;

  fs.mkdirSync(tmpPath());
  fs.mkdirSync(tmpPath('cwd'));
  fs.mkdirSync(tmpPath('cwd', 'hello.js'));
});

IMO, the first version even looks better and less confusing.

[schnittstabil]

@vdemedes Thank you for reminding me of destructuring assignments, these will really help a lot.

Having t.context as a function is not logical to me.

Btw, but only if you are interested in logic (set theory): mappings like {foo: 'bar'} are sometimes considered as functions (more or less: key => key === 'foo' ? 'bar' : undefined), thus they are absolutely logical to me 😉

[sindresorhus]

We did not predict that someone would assign t.context a function.

I did. That's exactly why I made reassignable, so you can use any value you want, including a function, or you know boolean if that's what you want. It's the same as default and named exports. Sometimes you only need one thing and it's nice that you can just use it directly.

And don't forget, in JS, functions are objects. (()=>{}) instanceof Object //=> true

[jfmengels]

Sometimes you only need one thing and it's nice that you can just use it directly.

True, but the name would then not necessarily be very appropriate. But that is then up to the developer.

Nobody added labels to this, but I understand that you want to support this @sindresorhus? That'd be fine with me.

[schnittstabil]

Nobody added labels to this

@jfmengels As this is not a change request per se, feel free to label this issue as question, discussion or similar – I'm not allowed to.

[sindresorhus]

@jfmengels Still a discussion. Nothing decided yet. Just shared my view of it. I might be wrong.

[jfmengels]

Sure. I feel the same as @vdemedes. Even though it's possible, I don't think that having t.context be a function is a good thing, mostly because the name doesn't make it explicit what it is doing setting up (or at least, I don't see cases). I think it's much better to encourage t.context to be an object with properties with explicit names.

[schnittstabil]

As t.context is set up per file, I think it depends how one want to divide their tests into files.

Non-Function Example: Integration tests

Integration tests run within the context of a server, thus the following feels right to me:

// test/server.js
let port = 8000;
test.beforeEach(t => {
    t.context = createServer(port++);
});

Although the example above is not about functions, t.context is clear within test/server.js to me, thus I think it's reasonable and convenient to use t.context instead of t.context.server or similar.

Function Example

The following example (using rename-fn) is a bit synthetic, personally I wouldn't do that, but maybe someone else come up with a better use case?

// test/named-function.js
test.beforeEach(t => {
    function foo() {}
    t.context = foo;
});

test(t => {
    t.is(t.context.name, 'foo');
    renameFn(t.context, 'unicorn');
    t.is(t.context.name, 'unicorn');
});
// more named-function tests…

// test/fat-arrow.js
test.beforeEach(t => {
    const foo = () => {};
    t.context = foo;
});

test(t => {
    // same as above
});
// more fat-arrow tests…