Simple question, when the test is done executing, does the Start item in the Run menu become enabled again ? I see it disabled for a period while my test is running and then become enabled again. I ask because I've been running Jmeter for 3 days and don't see the tests completing but see start become re-enabled.
Cheers
There will be an indicator at the right corner. When the execution is going on there will be green signal shown at this location when it gets completed the green notificatuion is not shown....
The only thing I've seen that seems to be a clear indicator that tests have completed is that when you start a test by clicking the green "Start" button, the button becomes grayed out, and looks disabled. It re-enables when the tests have stopped.
So just look at the Play button's state for an indicator of whether or not the test is still running.
Related
Currently i'm on a project which has some main loop which is quite slow. Putting a breakpoint into it implicates i have to press F9 each time, and there are a lot of iterations. What i imagine is to see the program 'move' on one of my screens, without wondering if it is stuck or not.
I already have log outputs and so on, my question really focuses on this 'show debug without stop' feature.
What i imagine is to see in this main loop the current line highlighted as i it was a line-by-line execution, but without breakpoints and without going down in the subcalls.
Does any of you know a way to do something like this or wish the same thing ?
Thanks !
Your Debug tool window has a "Mute breakpoints" control:
If you leave it ON, your application won't stop at breakpoints. You can switch it off later once you reach the point where you actually want to start debugging (e.g. mute breakpoints while the app is doing all the initial loading tasks, while you navigate to the screen you want to debug etc. and then unmute them).
I'm not quite sure this is it but , how about disabling focus on breakpoint:
Put your cursor on the line you'd like to breakpoint and hit ctrl-shift-f8 (on a pc). You can choose not to suspend when a breakpoint is hit, and/or you can add logging that the breakpoint was triggered. If you need to, you can add a condition that must be met before the breakpoint is triggered.
Here's what this looks like for me:
In all of my searching, I have not come across any trick, plug-in, or setting that would allow me to pre-populate a Watch Window for use during debugging.
The well-known steps to watch a variable in Visual Studio 2017 is to set a breakpoint (perhaps on the first instance of a variable being assigned a value), then, adding the variable to a Watch Window. On subsequent runs, that watched variable should remain in the Watch Window.
Is there a way to accomplish pre-populating the Watch Window before a debugging session? I have code that runs in a timed sequence. Taking the extended time during an execution break to pause and set up a watch causes the program to crash. Such timeout crashes while setting up variable watch objects makes for difficult interaction with the debugger. Pre-populating the watch list would help considerably.
I know that I could use a technique such as using Debug.Print(...) statements, which are printed to the Output Window during code execution. However, this doesn't allow me the control and visual feedback to my debugging efforts that comes from a Watch Window.
Watches can only be evaluated when you are paused in the debugger, say on a breakpoint. They can't be evaluated during normal execution. Your options to get around this limiation are:
Add Debug.Print(...) or something similar to your code that outputs a value.
Similar to #1 add a TracePoint which you'll find in the actions setting of a breakpoints setting (that's the gear icon when you hover over a breakpoint). When the TracePoints are hit they will then evaluate the expression that you specficied in the actions window and log it to the Output window. The advantage of TracePoints over adding your own logging is that you can turn it off and on without building your code. More info at: https://learn.microsoft.com/en-us/visualstudio/debugger/using-breakpoints?view=vs-2019#BKMK_Print_to_the_Output_window_with_tracepoints
Use the VS Enterprise only feature Snapshots which is part of IntelliTrace. Basically set your breakpoints but rather than stopping on them to look at the watch just continue. Each time you stop a snapshot of the process will be taken capturing the state of your application at that time. Then once you're finished use the Diagnostic Tools window to select each of the snasphots and activate them. For each snapshot you can use the debugger just as if you stopped the application. So you can use watches and inspect etc. Of course you can't step as the app has already ran but you can go to the next snapshot etc. More info at: https://learn.microsoft.com/en-us/visualstudio/debugger/view-snapshots-with-intellitrace?view=vs-2019 and https://devblogs.microsoft.com/visualstudio/step-back-while-debugging-with-intellitrace/
How Can Watch Variables be Configured in a Watch Window Before Running
a Debug Session in VS2017?
I'm afraid the answer is negative.For now,the Watch window can only be configured after the debug session start.It's like a runtime window only occurs during debugging.
So we can't pre-populate it before debug session for now. In other words, it's by design.
As alternative ways,you can follow Andy's detailed suggestions above.
And since your needs is meaningful in some specific debugging situation, you can also post your suggestion on development community like a user voice to add a new feature.
I'm using WebStorm 2017.2.2 to develop and run some mocha tests.
All is going pretty well, but the tests never finish. It gets done with running all of my test files, then just sits there spinning saying "Running Tests."
If I hover over the red box, it shows a tooltip that says: Stop 'Full Tests' (⌘F2). It also shows "Stop Process" at the bottom of the IDE. So, I click it, and the red box turns into a skull.
Now, if I hover over the skull, it shows a tooltip that says: Stop 'Full Tests' (⌘F2) (same as before). It also shows "Kill Process" (different) at the bottom of the IDE. So, I click it, and the IDE stops saying "Running Tests" and now says "Test Results."
How do I configure WebStorm so that it automatically ties up those loose ends when it reaches the end of my test suite?
To answer this, the mocha docs state that autoexit is not a feature in v4, basically something is stopping the tests from exiting, to revert back to the v3+ way of exiting when your tests pass, use the arg --exit in your test configs under Extra mocha options
https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit
Long story short, I am debugging a big application which I didn't write. It is throwing an error when it runs on the server on which it is supposed to be run, so I am testing on my own machine with the debugger attached to see what happens.
It has thousands of lines of code, and has been running for a couple of hours now. I want to know which line of code is currently executing, so I can get a rough idea of how long is left, but I don't want to Break All as the code is...rickety.
Short of firing watchpoints all over the place in a spray and pray fashion, is there a non-invasive way to see which line of code is executing right now?
Thanks
Process Explorer can show the currently executing line and call stack in the process.
Right-click a process, click Properties, and then click the Threads tab.
I am using Code::Blocks 12.11 on Windows 7.
I am writing small programs for learning and they don't appear to contain any infinite loops but regardless, Build->Abort does not work in those situations in which I find that I have to use it for some reason after Build->Run.
In this most recent case, the following is displayed in the "Build log" tab of the "Logs & others" window at the bottom of the screen.
Checking for existence: C:\CodeBlocks\Test_Cpp11\bin\Debug\Test_Cpp11.exe Executing:
"C:\Program Files (x86)\CodeBlocks/cb_console_runner.exe"
"C:\CodeBlocks\Test_Cpp11\bin\Debug\Test_Cpp11.exe" (in
C:\CodeBlocks\Test_Cpp11.)
I exited Code::Blocks, came back in, reopened the project, and immediately ran the program and it ran fine.
EDIT: I found out the problem. If the "console window" - that came up to display cout statements - is still open, then you will have a greyed out Build->Run and Build->Build items until you close that window. My assumption that I needed to do Build->Abort at that point was incorrect. As pointed out in the answer below, that would not abort a running project process anyway, only a build/compile process that may be running.
THis happens when the previous execution is not terminated properly.
On windows, Open up the task manager and kill the commandline processes which contain the output of the previous run. Doing so will restore the build / run to icons to green and they are rendered available.
To kill the running process while you are debugging, click on the red-color 'X' button on the debug bar. This is the button named "Stop Debugging" in the image shown below.
In Code::Blocks, the Build->Abort menu item will abort building (making or compiling) your project. It has nothing to do with killing a running process. Hope this helps you.
When the application has completed and returned from its main function, it will prompt you to "Press any key to continue".
Once you do so, this will abort the launched process and the build buttons will no longer be greyed out.