Adds support for parameterized tests

[KostkaBrukowa]

Hey!
This is a PR that allows to see and run parameterized tests in the summary window.
The main algorithm here is:

1. Run the treesitter queries on the test file.
2. If the file do not have any parameterized tests (it.each, test.each etc.) do not do anything special just return normal test positions
3. If file contains parameterized tests then:

• run jest to discover every test in the file
• find all of the test results from jest that are on the same position returned by treesitter
• add new positions to the position returned by a treesitter

Closes: #2

How to run:
Checkout neotest-jest to my branch
Demo:

Screen.Recording.2022-12-27.at.20.29.03.mov

TODO:

• add support for test.each and it.each
• add support for describe.each (maybe in different PR)
• add a configuration option to enable this behavior
• fix running single parameterized tests (for now if we run e.g. run_nearest jest skips them
• fix race condition when running test before it updates its name
• some unit tests

[rcarriga]

Saw you were blocked by the neotest PR, so got it merged 😄 Very cool to see this!

[KostkaBrukowa]

I think that the PR is ready for testing. If someone has the time to checkout to this branch and report any problem I would be grateful.
Unfortunately jest command with jsdom test environment can be really slow (in my bigger project it can take up to 7 seconds) therefore the discovery is slow. If anyone has any ideas that can speed up this process it would be nice to use it here.

[primeapple]

I'm going to test this.

[primeapple]

Could you update your description, because the referenced blocking PR on neotest is merged, as @rcarriga stated.

[primeapple]

Suggested change

	jest_test_discovery = false,
	jest_test_discovery = true,

Did you mean this?

[KostkaBrukowa]

acutally I meant to use false here, because if someone does not diable discovery key and automatically will update the plugin, this option will run jest commands on all of the files in the project. I think that this solution should be opt-in

[Jamie-505]

but wouldn't it be misleading if the e.g. for enabling the discovery displayed the value as false?

[primeapple]

I have tested this a bit. Works very well. I really like the idea of resorting back to jest to discover the tests. This saves reimplementing all the logic.

Do you think this is mergable?

[KostkaBrukowa]

I think after resolving conflicts its mergable. I'll try to resolve them today

[primeapple]

I think I found some bugs. Consider the following test:

describe.each([null, undefined])('thing', (value) => {
    test('is null', () => {
        expect(value).toBeNull();
    });

    test('is undefined', () => {
        expect(value).toBeUndefined();
    });

    test('is not truthy', () => {
        expect(value).not.toBeTruthy();
    });
});

1. Running the whole file marks the describe block as failed, the first test as failed, the second one as success (WRONG), the last one as success.
2. Running only the second test marks it as success (WRONG)
3. I don't know if this is because of your changes, but see the following test:

describe('thing', () => {
    const value = null;

    test(`is null`, () => {
        expect(value).toBeNull();
    });

    test('is undefined', () => {
        expect(value).toBeUndefined();
    });

    test('is not truthy', () => {
        expect(value).not.toBeTruthy();
    });
});

Now try running only the first test (with the backticks in the testname). It does not work, this test does not get a success/failure symbol, instead the whole describe block is being run.

[KostkaBrukowa]

So about the first scenario -> this is a limitation (or not) of the plugin. If you have describe.each([null, undefined])('thing', in your describe and you dont use each name in test name (e.g. thing $s) all the tests will have the same name:
from first run: "thing is null", "thing is undefined", "thing is not truthy"
and from the second run: "thing is null", "thing is undefined", "thing is not truthy"
so we cannot get the names from the output. If you look into some other IDE's there is the same problem there but maybe more visible. I have no idea on how to fix it in the plugin. In the code it would be

describe.each([null, undefined])('thing $s', (value) => {
    test('is null', () => {
        expect(value).toBeNull();
    });

About the second scenario: its the problem on master branch #46

[primeapple]

Then I'm fine with merging it :)

[primeapple]

I use this for months now and it seems usable and stable. Any option of merging and/or reviewing it @haydenmeade ?