Thingsboard IoT Payload Decoder Unit/Integration Tests for TBEL

Question

At our Company we have a running Thingsboard PE Instance. Just recently, we started to migrate all our Rule Chains, Converters and Scripts from Nashorn JS to TBEL. We have a lot of devices from different manufacturers. They all provide us Payload Decoders in JS Code, so we could basically just copy+paste them in the past. But now, that we want to use TBEL, we need to basically re-code them ourselfs. This causes a lot of insecurity and we want to setup a test environment, that monitors all changes made to certain Decoders and runs Unit+Integration Tests. We use the VCS Auto-Commit Feature from Thingsboard, so we could just put some Test-Framework Code in our Git Repository and build a CI/CD Pipeline inside Git to automatically test every commit.

My Question: Does somebody has experience with Testing Payload Decoders written in TBEL? Maybe a clever Strategy we could use? Or in General, how do you test your self-written Payload Decoders or other Thingsboard Rule Chains in General?

Thanks for any help

I just want some tip-off.

Answer 1

Okay ... a bunch of Tip-offs. Having worked with other tools like this ... a bunch of (well informed) assumptions

1. You can extract the js code from the json where it is stored. A decoder is self contained.
2. You need to execute it in context of the unit test ... simple way to do this: Wrap the exported code into its expected function including params ...
3. now either eval() or go down the rabithole that is module.constructor() ... a way to build an eval with common js attached. (i am sure there is another way using the infrastructure that runs import etc)

Downside: the code is generated dynamically and every error will lead you to just a loc in a eval or another loc in the module.constructor version. Looking at how tb works - I am experimenting with building something that can compile a function and attach it to the thingsboard.json export .... so I am working with a real file, that i am exporting to tb json. In opposition to the here described way: importing from tb json and the running in a test.

I hope all this makes sense.