Set up testing and CI

[felixfbecker]

If anyone knows how to do this, help would be appreciated

[felixfbecker]

With the increasing amount of issues, I had some thoughts on this:

• Refactor DebugSession.run(PhpDebugSession); into a run.ts file that imports PhpDebugSession

In the tests:

• construct a new session with new
• connect to it with a Node socket
• send it valid XDebug messages over the socket
• call PhpDebugSession request handler methods with valid VS Code protocol message object

Problems:

• How to run mocha with ts tests
• PhpDebugSession request handler methods are protected, how can they be called from tests?
• Instead, another option would be to child_process.spawn the debug adapter and talk to it from stdin / stdout just like VS Code would
• Even another option would be to mock methods with SinonJS and assert on call with specific args etc.

Thoughts?

[weinand]

@felixfbecker I'm working on a test suite that uses the approach you've mentioned above:
"Instead, another option would be to child_process.spawn the debug adapter and talk to it from stdin / stdout just like VS Code would"

[felixfbecker]

@weinand I started on using that approach, but ran into a few issues:

• For tests there needs to be a high-level API to send request, it is not acceptable to write raw Buffers to the stdin stream and parse the stdout manually.
• It is going to be hard to split these tests up into isolated tests. For example, if you use mocha. Lets say you have a test (describe) for launchRequest, one for setBreakpointsRequest etc. But you can only test the setBreakpointsRequest after you also send a launchRequest. So you have 2 options:
  • couple your tests. make the spawned debug adapter stateful and simply make sure the launchRequest test comes before the setBreakpointsRequest test. This is definitely an antipattern.
  • Write helper functions that setup and teardown the debug adapter for each test in isolation, from spawning, initialization to the needed requests that need to be done beforehand. I got stuck on this.

If vscode-debugadapter-node included a class for mocking VS Code in tests, that provided an API like sendSetBreakpointsRequest() etc, that would be extremely helpful.

[weinand]

@felixfbecker this is what I am working on:

• A high-level (most likely async/await based) API to send requests.
• A framework that sets up and tears down the adapter for each test (and deals with events returned from the adapter).
• Every test tests a specific VS Code scenario: e.g. "set and hit a valid breakpoint", "set a breakpoint that resolves to a different location", etc. For every adapter you will have to adapt the test suite because not every test makes sense.

[felixfbecker]

👍
By async/await you probably mean promise-based, right? Since TypeScript only supports async/await for ES6, and then Node will throw up on the default parameters.

[felixfbecker]

@weinand as far as I can see you have written these classes in https://github.com/Microsoft/vscode-node-debug/tree/master/src/tests. I think they would make much more sense in their own NPM module so they could be added as devDependency. Will this happen anytime soon or should I copy the files over to my project?

[weinand]

@felixfbecker I will make this available as part of the npm module after GA (end of March). Until then
I suggest that you copy the files, use them and provide feedback!