Test framework

[staff0rd]

Are you open to the inclusion of an automated test framework?

I'd like to contribute to the project but find it difficult to do without an automated way to prove bug fixes and test features.

[AnWeber]

Gladly. I've just been too lazy to do so. Am also open to suggestions as to which one should be used.

[staff0rd]

Here's an example using jest #120

[AnWeber]

I already know jest. I just do not like the new dependency to babel. I would have a quick look at ava as a test runner, otherwise I would probably be with jest too.

[AnWeber]

Background for the slight reservations against jest is the lack of esm support (issue list). Some dependencies (got, clipboardy, globby) switch to ESM-only modules. Since got is really important, I am considering switching to esm in the medium term. And got uses ava as test runner, that's why I would want to take a quick look at it. And for mocking Sinon is used.
So far I've personally only used jest (and I prefer jest over mocha).

[staff0rd]

Appreciate the ESM support issues. The approach here to add ava also does not support ESM, however the approach noted here got me pretty close, but it needs further changes. Even so, Sinon does not stub esm out of the box so the test still fails.

I also had to add timeout: 30s to have ts-node not timeout. Another approach is to use https://github.com/avajs/typescript which expects precompilation - however this requires ava@next and from what I understand a complete migration to esm - I was unable to get this approach working.

Finally a tiny comparison between ava & jest:

• the usage of sinon means when calls like t.true(spy.calledWith('httpyac v1.2.3')); fail, the user must add their own console.log(spy.getCall(0)) and run ava with npx ava -v to find out what was actually passed - whereas mocking is part of jest and on fail the passed arguments are printed
• no nesting (like describe > test), so every test must be in a single file
• differences in mocking api (sinon):

sinon.stub(utils, 'parseJson').callsFake(() => Promise.resolve({ version: '1.2.3' }));

vs

jest.spyOn(utils, 'parseJson').mockResolvedValue({ version: '1.2.3' });

[AnWeber]

really thanks for your efforts to contrast ava and jest. I think you are right about jest and it is currently the better choice.
ESM is a larger conversion effort and one must also still see whether the VSCode extension can also be written in ESM.
Unfortunately I have conflicted the pull request by implementing prettier. Can you possibly rebase this again and resubmit. Or I can also do it, but then I would probably have lost you as author

[staff0rd]

Ya no problem, I will do this evening.

[AnWeber]

I would make a test folder in the root. The alternative with folder __test__ next to the source files would also work, but I think more understandable this way. I just had another error locally with me in the UnitTest. I would like to fix it before the merge, but I can't do it right now. It seems that I only had that one locally. Github Action runs through.

[AnWeber]

Thank you for your efforts. I have merged the jest PR. Thanks 👍😊