search

vitest-dev / vscode

VS Code extension for Vitest
https://vitest.dev/vscode
MIT License
736 stars 83 forks source link

feat: better debug support #334

Closed sheremet-va closed 4 months ago

sheremet-va commented 4 months ago

This PR improves the debugger support by utilizing the new inspector option. Also, a new option was added: vitest.debuggerAddress. With the vitest.debuggerPort, I think we can close #185 now.

Fixes #320 The debugger requires Vitest 1.5.0, but all other features work as they did with 1.4.0

ffMathy commented 4 months ago

Would introducing some kind of state machine pattern help? I feel like it's one of those problems that could be solved by this.

sheremet-va commented 4 months ago

Would introducing some kind of state machine pattern help?

Can you be more specific?

ffMathy commented 4 months ago

Well, let's say that when pressing a particular button (like "start") has different effects in different states.

Maybe when we are in the ContinuousRun state, that button does something else than when we are in another state.

We can represent each state as a class implementing a particular interface with various inputs (onStartClicked) etc, and also allowing each state to control what other states are allowed to be switched to and from.

It's similar to the strategy pattern in a way. I don't know the specifics of the problem, but it sounds like you're describing complex flows that apply differently in particular states.

Can you describe the flows more detailed? Then I can come up with something probably.

Alternatively, for me, it helps drawing it as a state machine on a piece of paper.

ffMathy commented 4 months ago

More info: https://en.m.wikipedia.org/wiki/UML_state_machine

ffMathy commented 4 months ago

And the pattern (you can create variants of it though): https://refactoring.guru/design-patterns/state

sheremet-va commented 4 months ago

We can represent each state as a class implementing a particular interface with various inputs

I see what you mean now, but the problem here is not that we can't organize it, but that it's not possible to do several things at once - for example, you can't debug a test and collect other test files at the same time because Vitest only supports a single pool (it blocks other test runs until the current one is completed).

ffMathy commented 4 months ago

Then each state class can have a property called "canDebug" etc, to represent that.

sheremet-va commented 4 months ago

Then each state class can have a property called "canDebug" etc, to represent that.

Again, this has nothing to do with the code architecture. We need to be able to collect tests despite the debugging, single Vitest instance just doesn't allow that.

ffMathy commented 4 months ago

Ah I see. My bad.