Tech Tips: Test Lua Scripts from the Momentum Console

Peter Lavin
Feb. 25, 2014 by Peter Lavin

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.

Running into the same old issues whenever you try to send high volumes of email? You need Momentum, the all-in-one platform for email, mobile, integration and analytics. Get the Overcoming the Challenges of High Volume Sending white paper today!

Overcoming The Challenges of High Volume Sending

2 Comments

  • 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.

  • With the limitations indicated, then why not simply test throughout the applied stand alone Lua interpreter, usually located at /opt/msys/3rdParty/bin/rclua

Related Content

How to Protect Your Personal Devices From Online Security Threats

With the slew of new technology gadgets, there is an increased risk of mobile and online security threats. Here are a few tips to keep your devices safe.

read more

5 Best Practices for Security Notifications

Learn the 5 best practices for security notification emails that product teams can use to build user trust and confidence.

read more

What GoT’s Casterly Rock Can Tell SaaS About Email Security

The defenses and vulnerabilities of castles in Game of Thrones should be a warning for SaaS providers about phishing and email security.

read more

Get started and start sending

Try SparkPost and see how easy it is to deliver your app’s email on time and to the inbox.

Try Free

Send this to a friend