stevedlawrence commented on issue #301:
URL:
https://github.com/apache/daffodil-vscode/issues/301#issuecomment-1338083024
Personally, I find option 2 much more legible and is much more likely to
reduce duplication if multiple tests need to stop a debugger.
I'm not sure if it's possible in typescript, but in the Daffodil CLI, we do
something that looks something that might look like this for debugger tests:
```
runDebugger(...) { debugger =>
// test logic that uses debugger
}
```
The stuff in the brackets is an anonymous function that accepts a `debugger`
as a parameter. So the `runDebugger` does whatever initialization is needed to
create a debugger (which might be os specific), passes that "debugger" instance
to the anonymous function to actually do real testing logic, and then when that
anon function returns, the runDebugger does whatever cleanup is needed (which
might also be os specific). This way all the os specific startup/shutdown logic
(e.g. find the .bat/no .bat file, kill a process) can be in the `runDebugger`
utility, and then the debugger logic in the anonymous function doesn't have to
do any os specific stuff or even think about cleanup--it's just all handled by
the `runDebugger` function.
The CLI Integration test utilities has a `runCLI` function that does exactly
what I describe, though it's a bit complicated because the initialization logic
is fairly complex to support threads vs processes and set up our testing
infrastructure.
https://github.com/apache/daffodil/blob/main/daffodil-cli/src/it/scala/org/apache/daffodil/CLI/Util.scala#L185
This approach might be overkill for the vscode tests though, it's not clear
to me how often you need this kind of pattern.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
