Quick Tip for Testing OpenWhisk Actions Locally

This post is more than 2 years old.

January 10: So after posting this yesterday, Carlos and I found some issues with both the 'hack' recommendation you add to your code as well as the test script. I've rewritten the post to reflect those updates. If you read this article already, be sure to read it again for the latest version.

I'd like to share a quick tip for working with OpenWhisk. Credit for this goes to my coworker Carlos Santana. When working with OpenWhisk, you need to deploy your code to the cloud in order to test it. This is a very quick operation (and can be even quicker with the Visual Studio Code extension but it can be a bit annoying if you are working on something complex. It would be cool if you could test directly on your machine without the 'copy to OpenWhisk' command, right?

You can do this with two quick changes. First, possibly modify your action to add the following code at the end:

exports.main = main;

Why do I say possibly? Because if you are using a 'zip file as an action' feature (which I'm blogging about in a few minutes), you will already have this line of code.

Next, use this script. I have all my OpenWhisk stuff in one folder where I'm testing, so I called this test.js:

const actionToRun = process.argv[2];

let params = {};
for(var i=3;i<process.argv.length;i++) {
	let [name,value] = process.argv[i].split('=');
	params[name] = value;

const action = require(actionToRun).main;

let result = action(params);
.then(result => console.log(result))
.catch(error => console.error(error));

This too is code from Carlos although I modified it a bit to make it more generic. Now I can do this at the CLI to test:

node ./test.js rsstest/main param1=paramvalue param2=paramblah

Of course, on the Mac, I could add the shell thingy on top so I could skip including "node " in front as well. (As far as I know you can't do that on Windows.)

Anyway, I hope this helps!

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA https://www.raymondcamden.com

Archived Comments

Comment 1 by Carlos Santana posted on 1/10/2017 at 7:14 PM

For running the test and not worrying about linux vs. windows I like to use npm run-scripts [1]
This means editing your package.json and then using `npm test -- ...`
"scripts": {
"test": "node test.js"

[1]: https://docs.npmjs.com/cli/...

Comment 2 by Dascalita Dragos posted on 1/11/2017 at 8:12 PM

Nice article. I've also taken a similar approach when I've created a sample hello-world function with unit tests and code coverage: https://github.com/ddragosd...

Comment 3 (In reply to #2) by Raymond Camden posted on 1/11/2017 at 10:15 PM

That's pretty cool!

Comment 4 by Raymond Camden posted on 2/13/2017 at 4:25 PM

As just an FYI, I changed the console log to:


This ensures the entire result is shown and nicely formats it.

Comment 5 (In reply to #4) by Carlos Santana posted on 2/14/2017 at 5:40 PM

I'm allergic to tabs and 4 spaces, I'm a 2 spaces dev 😃
This is my version JSON.stringify(result,null,2)

Ref: https://mdn.io/stringify

Comment 6 by trieloff posted on 5/7/2017 at 6:11 PM

I should have read the comments first, but here is my test script: https://medium.com/@trielof...

Comment 7 (In reply to #6) by Raymond Camden posted on 5/8/2017 at 1:46 PM

Impressive - thanks for sharing and making it awesome. :)