Next jv

[Josverl]

Addressed a few items

• [x] pick a random port per VSCode instance to avoid terminals conflicting with each other
• [x] fixed packaging by matching version of vscode engine
  • [x] fixed log.debug logging as log.error
  • [x] accept more board signatures in welcome message
  • [ ] try to remove terminals and disconnect devices on deactivate ( needs more testing)
  • [x] path manipulations using path.join or posix.join to allow for cross platform use
  • [x] add .rootPath andupdate logic and tests (still hardcoded to '/flash' but now all in one place #224

[Josverl]

I have a hard time with validation of the above and more the changes for windows paths as the integration tests are not working on windows, and debugging them is complicated by :

• a non standard test framework with very little documentation( I know its familiar to you ) but to allow me to contribute i would rather use supported framework preferable with some VSCode extension to make testing simpler and more consistent.
• currently is not possible to just run one test , that requires changes to the test code
• also there is no support to skip or run tests conditionally ( other than in raw code)
• AFAIK there no option to mock objects / or devices
• a lot of tests (apparently) have dependencies on other tests, but it is not clear how and which test should be run before others. (e.g. what other test(s) are required before running can upload a file which currently fails ?
• it is quite hard ( hardly working at all for me ) to try to debug / step though calls to the micropython-cntl-cont code. I'm not sure if that has to do with the JS--> TS calls but I cant make it just work for me, and hooking up a hardware serial debugger just to see what happens on the repl should not be needed.

I understand that there a groups of tests that make most/only sense when run in order, but currently there is only one possible path for all integration tests, and that currently blocks me in in validating (possible) fixes as there are multiple tests that fail to run in my setup that seem to interfere with the other tests.

I would welcome a framework such as mocha or jest are there are more than a few samples to make vscode extension testing work , and also work in GHA pipelines which would help catch cross-platform bugs.

[Josverl]

Possibly the integration repl test fail as a result of the the terminals not being closed correctly at the end of a test ( or at all ) the clue is that multiple terminals to the same device are showing when running the integration test twice :

another possibility is that the response to the test command is sent / received by the host in multiple chunks, and that the function nextTerminalData only processes the first chunk received.

❌ can use print command  738 ms
node_modules/probs/lib/reporters/consoleReporter/consoleReporter.js:11
AssertionError: 
- Expected
+ Received

  print("foo")
- foo
- >>> 
+
    at Object.<anonymous> (/home/jos/pymakr-vsc/test/suite/integration/devices.test.js:44:16)
    at async [file:///home/jos/pymakr-vsc/node_modules/probs/lib/test.js:41:13]()
    at async processQueue ([file:///home/jos/pymakr-vsc/node_modules/probs/lib/utils/misc.js:57:32]())

[jakobrosenberg]

Thanks for this PR @Josverl. I skimmed it and it look great. I'll review it ASAP and get back to you.

As for testing: I wanted to use the default testing tools (Mocha IIRC), alas I ran into countless issues with integration testing. Eventually after a few days I gave up and installed Probs, which just worked.

The main problem is that testing frameworks are limited to child processes or workers for running tests. This means that they can't access the extension instance directly. It's the same reason that integration tests have to be run from the debugger tab and not the terminal.

With Probs I can use --runner main and have the tests run in the main thread which has access to live extension API. (Granted that I run it under the debugger)

Tests are run in the order that they're written, eg.:

// tests listed by their execution order
test("1", () => {
  test("2", () => {
    test("3", () => {
      test("4", () => {});
      test("5", () => {});
    });
  });
  test("6", () => {});
  test("7", () => {});
});

This makes dependencies easy to reason about, but you're right about the lack of documentation. I'll see if I can do something about that.

FWIW, I tried your branch and all tests, incl. upload, passed. 🥳

[jakobrosenberg]

Great Scott! I think I got integration tests working outside the debugger.

I'll merge this PR and then create a new one to get command line support for the integration tests.

[jakobrosenberg]

:tada: This PR is included in version 2.8.7 :tada:

The release is available on:

• Visual Studio Marketplace
• GitHub release

Your semantic-release bot :package::rocket: