Testing your Lua scripts can sometimes be a bit tedious. It usually involves injecting a message in order to trigger the callout that will execute the code and output a message to the log. You must then open the log in order to check the log entry.

There is a better way. The Momentum console is extensible so you can add a command used solely for testing code. This does away with the need for injecting a message and looking for log entries in paniclog.ec.

Console Command

require(“msys.core”);

require(“xml”);

local function test_code(cc)

— put code you wish to test here

local doc = xml.parsexml([[<doc></doc>]]);

local node = doc:root();

local child = node:addchild(“item”);

child:attr(“name”, “Junior”);

child:contents(“I am a child node.”);

— use print for console output

print(node:tostring());

end

msys.registerControl(“test_code”, test_code);

Comments

This code uses the XML library so it must be included.

Choose whatever name you wish for your function. The parameter passed to a control function is control construct userdata — we needn’t be concerned with it here but if you do want to pass an argument to the console command access it in the following way: cc.argv[1]. The code that you want to test goes inside this function.

This print statement will output node as text, verifying that the XML object has been created. You do not need to send a test email or check for log entries in paniclog.ec.

You must use the msys.registerControl function to register your console command. You can register any number of commands from the same script file so, if you wish, you can keep adding functions.

Test your code by issuing the command /opt/msys/ecelerity/bin/ec_console /tmp/2025 test_code. Invoking the console in this way-in batch mode-executes the command test_code and immediately exits the console. You should see output such as the following:

<doc>

<item name=”Junior”>I am a child node.</item>

</doc>

Errors will also be output to the screen. For example, if you attempt to pass nil to the child:contents function you will see the following error message:

…/msys/ecelerity/etc/conf/global/lua_scripts/ec_console.lua:21:

bad argument #1 to ‘contents’ (string expected, got nil)

The console provides a very convenient way of testing code but it has limitations. You have no access to userdata such as an ec_message so you cannot test message object methods. Additionally, some Lua functions can only be used during specific callouts and require that a message transit Momentum.

2 Comments

Message Systems Supporton Feb. 27, 2014 at 2:47 am

The cc argument is a custom variable type, so it’s not immediately obvious how it works. This lua variable contains two key pieces of data. The first is cc.argc, which contains the number of arguments that were passed.

The second is cc.argv mentioned above, which contains the actual arguments themselves. Interestingly, while Lua indexes from 1, the cc.argv array is really an interface to an underlying datastructure in C which is indexed from 0. That first value (cc.argv[0]) contains the string that was passed as the command (“test_code” in the above example).

Since there is no way to use standard table functions to obtain the size of the argv array, the above information is important if you want to be able to handle variable numbers of arguments.

One final note – it is advised to do this in a test system, and be sure you check your arguments. This flexibility is extremely powerful and thus is not without risk.

These commands run on the scheduler, and if the operation in the command takes too long it can cause a watchdog timeout resulting in a software restart.