rfc: supertest support

This could be technically out of scope for eslint-plugin-jest, but I’ve been using supertest, and some of our rules don’t really work nicely w/ it:

test('GET /live', async () => {
  await request(app)
    .get('/live')
    .expect('Content-Type', /json/)
    .expect(HttpStatus.OK)
    .expect('');
});

jest/expect-expect can’t handle .expect as a method being called on something, so I have to add request, which means I could forget a .expect and have problems.

It’d also be great to support warning that request needs to be either awaited or returned, as it’s a promise. I think this could be covered by one of our existing rules.

Using return also annoys jest/no-test-return-statement.

I don’t think we could catch every possible way of using supertest, and I’ve only just started using it myself, but I’m interested in gathering some initial comments & thoughts on if there’s any low-hanging fruit we could aim for that’d improve things w/o much work.

The main one for me is improving expect-expect to support .expect() - logic-wise easy, but the configuration would be interesting.

Theres also an argument that could be made about jest/lowercase-name supporting ignoring GET /live.

Right now, I’m feeling like this might be worth it’s own plugin at some point, but as far as I know theres no nice way of composing rules - instead you’d just have to clone rules like jest/lowercase-name into eslint-plugin-supertest, a la @typescript-eslint does w/ the eslint rules.

[SimenB]

I don’t think this belongs this plugin. Seems more natural in a eslint-plugin-supertest or whatever.

We use supertest at work, but we never use the assertions from it. Mostly because they don’t give proper stack traces.

test('GET /live', async () => {
  const { headers, status, body } = await request(app).get('/live');

  expect(headers.contentType).toMatch(/json/);
  expect(status).toBe(200);
  expect(body).toBe('');
});

(written free hand, haven’t looked up the actual APIs)

[G-Rath]

Thanks for that @erunion - would you mind opening that as a separate issue for tracking?

At least you should be able to put something like sinon.assert.calledOnce into assertFunctionNames and have it work.