Closed apobekiaris closed 5 years ago
on Help->About testdriven version is 4.3 on Tools->Extension it says 4.1
last note: Sometimes (I cannot understand when) even if the ProcessInvocation was killed (doubled checked the task mananager) for 10-15sec VS thinks that someone is using the TestDriven.NET.Debugger shortcut and then it releases without any extra action from me. I haven benn using TestDriven for years now but this strange behavior I encounter first time. I haven't update TD.Net recently and I am on 15.8.4 VS Enterpise.
This is an old issue and I was handling it with an AutoKey script to kill the ProcessInvocation manually however my workaround does not work well and sometimes VS gets confused about the CTRL+ALT+W,W after I kill the key shortcut and thinks I pressed different keys. I wonder if there is a better solution to this problem
Excellent question. What to do when the user requests for a test run to abort has always been a thorny question. Unfortunately test frameworks often don't have a way to signal that the test run should stop. The two obvious choices are terminating the thread or killing the test process (both of which have problems). These correspond to the Abort Test Run
command and right-clicking on the rocket in the tool and selecting Stop
.
The problem with detaching the debugger is that it isn't a TestDriven.Net command and it has never been enough of an problem to listen for a detach event and do something automatically. Another problem would be if I did kill the process, the rocket icon would be left behind in the tool tray (until the mouse hovers over it).
There is another possibility that might be a better solution to this problem. The test runner process currently looks for a "heartbeat" from Visual Studio and if it doesn't detect one it will cleanly exit (assuming that Visual Studio has been closed and it is no longer needed). I could extend the idea of a heartbeat to look for a debugger being attached and then detached (pulling the plug when a debugger is detached).
on Help->About testdriven version is 4.3 on Tools->Extension it says 4.1
Oops, thanks for pointing this out.
Could you give this build a spin and let me know how it behaves? TestDriven.VSPackage.zip
When you detach the debugger with tests running, the test runner process should detect this and exit.
Expect to see something like this in the output window:
I'm interested to know if you notice any unintended consequences!
thnks a lot for the patch.
the debeugger detaches and the Output you mentioned is displayed successfully. I will let you know if I notice something strange.
actually this is not failing test so focusing on the output after Sfift+F5 is counter productive as I need to Escape back to the editor. For tests that do not fail TD.NET does not focus the output and just displays the messages in the statusbar.
p.s.: I use an auto hidden output pane with Show Output before build starts
actually this is not failing test so focusing on the output after Sfift+F5 is counter productive as I need to Escape back to the editor. For tests that do not fail TD.NET does not focus the output and just displays the messages in the statusbar.
Ah yes, good point. This is the kind of unintended consequence I was wondering about. 👍
@apobekiaris,
Here's a new version that shouldn't focus the output window when the debugger detaches / the test process is terminated.
Let me know what you think.
I have TestDriven.NET.Debugger bound to (Ctrl+Alt+W,W) I run my test and at some point while debugger is attached i hit Shift+F5 and detached successfully. However when I try Ctrl+Alt+W,W again it fails with the subject message. This is an old issue and I was handling it with an AutoKey script to kill the ProcessInvocation manully however my workaround does not work well and sometimes VS gets confused about the CTRL+ALT+W,W after I kill the key shortcut and thinks I pressed different keys. I wonder if there is a better solution to this problem