Quick and easy on i am tiring to get the currently running script name. I was searching the forums but the word script and name are apparently in almost every post lol.
put my name
On a related note …
I want all my log messages to return the “(Current Suite).(Current Script) my message” but I don’t want to have to do this for each log, logwarning or logerror statement - is there a way to do this?
The only way to do this would be to override the logging commands. You can do this by creating a script that contains definitions for log, logwarning, and logerror commands:
to log
// log can take multiple arguments, so add the prefix to each
repeat with each item of the parameterlist
send log locLabel(@the target) & it to sensetalk
end repeat
end log
function locLabel theObj
put theObj's name into scriptName
put item -2 delimited by "/" of theObj's folder into suiteName
return suiteName & "/" & scriptName & ": "
end locLabel
I’ve attached a copy of a script that overrides all three of the logging commands. The script is called “logOverrides.script”. To use it, put the following line at the beginning of your script (assuming the overrides script is in the same suite as your script):
start using logOverrides
And any time that you call one of the logging commands, the overridden version will be executed.
This is exactly what I was looking for, thanks for the script Matt.
In my instance, I am inheriting Eggplant automation that has implemented multiple suites and even more scripts and having this functionality in the product using some out-of-the-box flags would have been really useful - please consider this my suggestion to improve SenseTalk.
Hello Matt,
I had an additional request for assistance around the same topic, when I get script failures I see this:
Fri, 10/22/10 8:51:49 AM FAILURE Screen_Error.tiff Image Not Found click Error - No Image Found On Screen: “MenuBar/Finder - File”
Execution Time 0:00:05 04 - FUNCTIONAL - Checkin Version - TestAssets on TorXServer into the Repository.script
Please help me override Eggplant’s Failure code as well to add additional information.
I tried:
to failure // log can take multiple arguments, so add the prefix to each
repeat with each item of the parameterlist
send failure locLabel(@the target) & it to sensetalk
end repeat
end log
function locLabel theObj
put theObj’s name into scriptName
put item -2 delimited by “/” of theObj’s folder into suiteName
return suiteName & “/” & scriptName & ": "
end locLabel
The reference to ‘failure’ seems to be incorrect as the failure message in my Run window looked the same.
Thanks in advance for your help!
Cheers,
Elliot
Nice! I’ve been looking for this functionality. Is there any way to also log the handler within the script?
put my caller
or something?
I missed that you wanted ‘the caller’ v/s the current script, please ignore my last msg to you.
The name of the currently executing handler is available as param(0), although you may find that not to be terribly useful. For much more detailed information about what is executing, including the script/handler that called the current one, the current line number within each handler, and so forth, take a look at the callStack() function.
As for modifying the failure reporting, that’s a little harder. When a script fails, it throws an exception. To change the reporting you’ll need to catch the exception at some point by wrapping your code in a try/catch block. You can then extract the information you want about the exception that occurred and either throw the same exception again, throw a modified or new exception, or log something and proceed.
You could easily write a high-level script to accept the name of a test to run and then run it with your own exception handling in place.
// runTest.script -- run a test script and report errors
params testName
log "Preparing to run test " & testName
try
run testName
catch exception
logError exception
end try
log "Finished test " & testName
In that very simple example, the logError command will simply display the error in about the same way that you see it now from eggPlant. You’ll want to do your custom error reporting at that point instead.
Despite its simple appearance, the exception is actually an object containing a lot of information. If you change that line in the example to
logError standardFormat of exception
you may be surprised to see everything that’s in there. See the description of “the exception” global property in the SenseTalk Reference for more information, but basically it includes the full callStack information from the point where the exception occurred, plus some other information that you can use in crafting your error reporting to suit your needs.
This is not my ideal solution as I have to update all my scripts to add try’s but I understand that it is an object, making this is necessary.