Refactor integration tests into unit tests

[Almenon]

Currently I really just have e2e testing - the tests runner runs vscode along with my tests. According to the test pyramid I should be focusing on unit tests, not e2e tests.

[Almenon]

see https://github.com/microsoft/vscode/issues/82471

[Almenon]

https://github.com/kenhowardpdx/vscode-gist/blob/develop/__mocks__/vscode.ts

Ken Howard mocks vscode w/ jest.

I don't want to add layering logic - arepl is tightly coupled w/ vscode and even if I did extract it the idea of layering logic seems like a lot of fluff to me that would reduce readability. I'd guess I'd still sorta have layering logic if I created a mock but it would in the unit test files so the vscode stuff would remain readable.

I suppose it's just a choice between mocking w/ jest or mocha

Jest:

• newer framework
• I like it better
• fresh start, don't have to worry about what parameters to pass to mocha to specify unit tests only vs. integration tests

mocha:

• I'm already using
• can run unit tests along with integration tests

[Almenon]

I ended up going w/ mocha. Not sure if it was the right decision (forgot another factor in favor of jest is that my company uses it so would be better to learn) but I got it working.

[Almenon]

Tried testing one method that was more tightly coupled w/ vscode and yikes.... that was not fun.

[Almenon]

More links: vscode-gradle unit tests: https://github.com/badsyntax/vscode-gradle/tree/master/extension/src/test/unit Discussion in VSCode: https://github.com/microsoft/vscode/issues/94746 SUSE unit tests: https://github.com/SUSE/open-build-service-connector/tree/master/src/test

[Almenon]

I already have unit tests, so I edited the title to be more clear. The end goal is to have most of my tests as unit instead of the 50/50 split currently.

[Almenon]

some more discussion: https://vscode-dev-community.slack.com/archives/C74CB59NE/p1625855640330600

pez says he uses jest and loves it. See https://github.com/BetterThanTomorrow/calva