How Do You Test Very Long Scripts?
Moderators: JRL, Dorian (MJT support)
How Do You Test Very Long Scripts?
I'm in the process of writing a macro that will take several hours to run and will consist of hundreds of lines of code. Clearly testing this is rapidly becoming a problem!!
I was just wondering how you guys test your long macros, do you laboriously comment out hundreds of lines at a time, do you copy sections of code into a new macro or is there a "run from line xx" button that I have yet to find?
-
Marcus Tettmar
- Site Admin
- Posts: 7395
- Joined: Thu Sep 19, 2002 3:00 pm
- Location: Dorset, UK
- Contact:
Use the debugger's breakpoints.
In the editor you can set the debugger to run from the current line instead of the top (Debug/Run From Top). You can set breakpoints and run to the breakpoint then step or run to the next breakpoint. So normally I'd run from the top to a breakpoint just before the section of code I want to debug, then step through that part.
Read this:
http://www.mjtnet.com/blog/2006/05/17/use-the-debugger/
In the editor you can set the debugger to run from the current line instead of the top (Debug/Run From Top). You can set breakpoints and run to the breakpoint then step or run to the next breakpoint. So normally I'd run from the top to a breakpoint just before the section of code I want to debug, then step through that part.
Read this:
http://www.mjtnet.com/blog/2006/05/17/use-the-debugger/
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
I'm currently on a script that is up to 3300 lines (including blanks and comments. The finished script will only take between 5 and 20 minutes to complete, this can still be annoying to test.
Luckily it's a script that consists of 4 different tasks. I wrote this script (with the help of some clever people on this forum) so that I can easily comment out blocks of code or bypass them to continue testing. use /* and */ to block sections and goto>label
Luckily it's a script that consists of 4 different tasks. I wrote this script (with the help of some clever people on this forum) so that I can easily comment out blocks of code or bypass them to continue testing. use /* and */ to block sections and goto>label
Hi RNIB,
One of the things I do is break a long script into many small subroutines. Each of the subroutines may be tested individually with a variety of inputs satisfied it works as desired and is reliable. Then test related subroutines together, and finally the entire script. Basically it is a divide and conquer stragegy.
Another reason for the subroutines is it is easy to get lost in a long continuous piece of code. Makes it easier to understand what the code is doing.
I usually avoid using goto>label because it is easy to make copy/paste errors where you forget to rename the label. However, limited use can streamline your script.
Another way of blocking out sections of code is to use an if statement.
Gale
One of the things I do is break a long script into many small subroutines. Each of the subroutines may be tested individually with a variety of inputs satisfied it works as desired and is reliable. Then test related subroutines together, and finally the entire script. Basically it is a divide and conquer stragegy.
Another reason for the subroutines is it is easy to get lost in a long continuous piece of code. Makes it easier to understand what the code is doing.
I usually avoid using goto>label because it is easy to make copy/paste errors where you forget to rename the label. However, limited use can streamline your script.
Another way of blocking out sections of code is to use an if statement.
Code: Select all
if>skip=TRUE
//do nothing
else
//execute this block of code
endif
