REading the help topic you referenced on this... In this case, "debugging" is a coding act, not a tool function. To "debug" code, in the days before IDE's that have a lot of bells and whistles, you would run your code, look for errors, fix them, rerun, etc. You would add specific code into your application you're debugging to do logging, etc., as you're running to be able to determine what is going on.
I just tried... and no, break points don't work. And, again, I can kind of understand why. While the extension is not encapsulated as a TCX, it is, in a way, "compiled" into TestComplete. There's a thread (or threads) in TestCOmplete that run the code in the extensions... the debugging of scripts with breakpoints and such are in a different thread entirely.
Now... I agree, it would be nice to have the breakpoints and such work. Feel free to make it a feature request and, when you do, I'll vote it up. But, in the meantime, what you're doing will work just fine, you'll just need to get a little more down and dirty in your code to figure out what problems you may be having. Add logging statements to expose variable values, code conditions, etc and then, after you run something, go back and check again.
If you truly want to use the breakpoints... then yes, you'll need to create some sort of test harness to test the functions of your script extension.
ok, thank you.
Yes, this actually should be a good (nearly expected) improvement.
I am surprises I am the first one who discovered this... honestly. When people write script extentions are they so good they don't make any mistake so they don't need to debug (real-time) as well as the other kind of scripts?
Debug scripts by log.messages brings me back to early 90s, which is something I did for a loooong time!
But I must be really bad on that!!! LOL
Anyway, we'll do our best to test the single routines in a separated script and eventually pack them into a script extension object.
Thank you very much.
Not the first one to notice, no... Just that those of us who do write them have gotten used to doing debugging "the hard way".
