Does anybody know if it's possible in Test Complete to run a test from a specific point in a function?
I see options like run routine, run test, run project.
Thank you,
Raluca
There is no way to start execution of a script test from a specific line, but it is possible to move the execution point to the desired line. You can set a breakpoint to the first line of a script routine and run this routine. Once the test execution is stopped at the breakpoint, use the Set Next Statement action to move the execution point to the needed line and continue the execution.
This feature is documented in the Setting Next Execution Point help topic.
TestComplete's Keyword Driven Tests have the possibility to add "Labels" and "Go To Labels".
You can put a label anywhere in your KDT script and set a GoToLabel at the very beginning of your test to move to that point.
It may even be possible to combine this with Project Variables to get a "Last Reached Milestone/Label". This is only speculation, but worth looking into it.
no there is no way you can run testcomplete scripts from a specific point. the closest point you can get to for runnning you script from a specific point is to use break point and then press F10 for executing one by one line of code
Related
I am working on a project where I have to send arguments by a command line to a python file (using system exec) and then visualize the results saved in a folder after the python file finishes executing. I need to have this by only clicking on one button, so my question is, if there is any way to realize this scenario or maybe if I can order the events.
Now I have included the flat sequence structure to the block Diagram so I can order the events, but I had an issue with making the program (the python file) running every time I press the Test button (it only runs in the first time I click on the Test button), I tried to use the while loop but I couldn't execute it again unless I restart the program.
The way you phrased your question makes me think that you want to wait until the command you call via system exec finished and then run some code. You could simply use a sequence structure for this.
However, if you need to do this asynchronously, i.e. launch the command and get an event when the command finished so you can draw the results, you will need to resort to asynchronous techniques like "Start Asynchronous Call" and "Wait On Asynchronous Call", or for example queues and a separate code area for the background-work.
Use "wait until completion?" input of System Exec function to make sure the script finished execution, then proceed with the results visualization part.
Can someone explain what is the purpose of the Step Over Thread and Step Into Thread debugger commands in Xcode? In what case is it useful to use them rather than the usual Step Over and Step Into? What is the difference and when does it matter?
Edit: To clarify the question, I'm not asking about the difference between Step Over/Step Into/Step Out, I'm asking about the difference between the normal and the "Thread" versions, and in what case one version is more useful than the other.
Step Into
Executes the current statement and then stops at the next statement. If the current statement is a function or script call, then the debugger steps into that function or script, otherwise it stops at the next statement.
Step Over
Executes the current statement and then stops at the next statement. If the current statement is a function or script call then the debugger executes the whole function or script, and it stops at the next statement after the function call.
Step Out
Steps out of the current function and up one level if the function is nested. If in the main body, the script is executed to the end, or to the next breakpoint. The skipped statements are executed, but not stepped through.
Argument is general About debugging so look at
What is the difference between Step Into and Step Over in the Eclipse debugger?
Looking at specific the focus is thread so you can look at your "multithread" application as single thread application without having multiple events/thread etc. running while you are stopped at break point. You have a "stable enviorment".
http://developer.apple.com/library/ios/#documentation/ToolsLanguages/Conceptual/Xcode4UserGuide/060-Debug_Your_App/debug_app.html
I just struggle with the same question. Question is a bit old but it looks like I found the proper answer.
Here in documentation, I found something like that:
Control-Shift to step into or over the active thread only while holding other threads stopped (the step icons show a dashed rather than solid line below the arrow).
Control-Shift-<Fx Key or click> are respective shortcuts for thread versions of step over and step into. So it looks like that this executes only current thread and suspending temporary all other threads. Normal versions continues execution of all not suspended threads.
a very simple explanation of this term:
Step Into, Step Over, Step Out Commands (Debug Menu)
According to this book:
Step Over Thread and Step Into Thread freeze all other threads while you advance the thread you're debugging. Hold down Shift and
Control while clicking the buttons, or select the commands in the
Debug menu, to get the effect.
I may sound silly, but I am naive in debugging.
I have one doubt, in order to track the flow of execution in a program, what should be the optimum point to put a breakpoint?
Is it so that wherever we will put a breakpoint, the application execution flow before that would not be traced?
The best point to place a breakpoint is where you need the function to break.
If that exact point will not be reached because of conditionals, break on the conditional that would cause it to skip and ensure the code you do want to debug will get reached.
You need to place breakpoints where you can get to the code you wish to debug the fastest.
You would place a breakpoint very near or just before a piece of code you want to step through in order to debug it, then when execution pauses at your breakpoint, step through line by line to examine the state of variables and follow the path of execution.
This is my problem, I've got a batch-script that I can't modify (lets call it foo) and I would like to count how many times/day this script is executed - to keep track of that data.
Preferably, I would like to write the number of executions with date and exit-code to some kind of log file.
So my question is if this is possible and in that case - how? To create a batch-script/something that works in the background and writes every execution of foo to a log.
(I know this would be easy if I could modify foo but I can't. Also, everything is running on WinXP machines.)
You could write a wrapper script that does the logging and calls the existing script. Then use the wrapper in place of the original script
Consider writing a program that interrogates the Task Manager.
See http://www.netomatix.com/ProcDiagnostics.aspx
You could, for example, write a simple Console app which runs on a timer; every 5 seconds it checks that your foo application process exists. If it finds that it does, it assumes that find as the start time of the application; if it doesn't find it, it assumes the application has now closed and logs that information. It wouldn't be accurate to the second by any means, but would give you a rough approximation of when the thing is running and closing.
You might be able to configure Process Monitor
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx to capture the information you require
I'm trying to watch the execution of a VB6 app and I'm running into an issue because once I enter the debugger and then hit Continue, it no longer lets me step through the code until I hit another break point. I want to be able to execute a program without stepping through something until I hit a point where I want to watch it execute. Ideally this would be something to the effect of holding a key down while I pressed a button to 'step into' that function.
Thanks in advance!
[EDIT]: I'm aware that I can use break points to stop the execution. To be more clear, the problem is that I don't know where the execution is going to, so I can't set the break point there (because I don't know where there is). That's why I essentially want to be able to say, 'after this next thing that I do, break, no matter what'. It sounds like this functionality does not exist, but I'm still keeping my fingers crossed.
While the code is running, press ctrl+break (or the 'VCR pause' button in the IDE) then press F8 (or choose 'Step Into'from the Debug menu in the IDE) to continue running the app. The next action will cause execution to break.
Note that the which causes the break will not always be the one you hoped it would be. Particularly annoying is the _MouseOver event which prevents you from doing a mouse down or a timer firing quckier than you can perform your action. Some breaks may even be fatal as regards running your app e.g. where Windows messages have been hooked (subclassing). Also consider there may not be an event handler in code (yet) for your action where it can break. But usually this technique identifies where you should be setting your breakpoint.
There is a Stop statement available for use in VB6 that will drop to the debugger when the statement is executed from code running through the IDE. (Just be sure to remove the all of the Stop statements from the code when compiling a release build.)
There are several techniques you can use.
These two have been mentioned
Using F8 and Shift-F8 to step through the program
Adding Stops (and later removing)
Others
Use a global variable to create a collection. Use it as a stack and have the subroutines you are interested in push and and pop strings. Conversely don't pop anything and you will get a trace.
Use Watches to monitor and break at selection conditions. You can setup just about any condition to break.
Make a Global String and have your procedures set when you enter them. Monitor it through a Watch.
Use Debug.Print in your code. Also Unlike Stop you can leave these in without effecting the production code.
Use the File System Object to create a text file to act as a log.
Sometimes problem only occurs in the Complied version then you need to use MsgBox or log to a text file. MsgBox can alter the behavior of complex user interactions with forms.
These are all techniques I used in debugging an application. If I had to monitor an application I would use Debug.Print. If that doesn't do the trick compile then log to a text file.
If you have something really complex going on then I recommend moving all your code out of the events into classes implementing a Command Pattern. Your commands classes should interact with the form through and interface.
In the Execute method of the command classes you will something like
<save the current state>
<Do your original code>
<save the modified state>
<push the command onto a stack>
What will happen is that you wind up with a list of all the commands you have executed (even things like mouseover) with the state they encountered and the modified state. You can then examine each object in turn to see what is happening. This is nearly the equivalent of creating Undo/Redo
Note however things like MouseOver can push a lot of classes on the command stack so you will have to structure your tests carefully or be overloaded with information. Remember you can always skip pushing the command onto the stack.
The downside of using commands is that you gone beyond debugging into redesigning. You will to decide whether the problem is worth doing this.
You can press the F8 key to step through the code line by line. Alternatively, you can press SHIFT-F8 to step through line by line.
F8 will step you in to a function, where SHIFT-F8 will step you over the function. If you click on the DEBUG menu in the VB IDE, you will see other options too.
EDIT:
You can also put a permanent break point in your code by using:
Debug.Assert False
By doing it this way, the 'breakpoint' is saved in your code. When you compile the app, debug code is ignored.