@gregoriusrippenstein/erlang-red-unittest 0.12.4 → 0.15.1

package/README.md

@@ -1,4 +1,4 @@
-## Unit testing nodes for Erlang-RED
+## Unit testing nodes for Erlang-Red and Node-RED
 
 Node-RED Nodes for testing flow correctness in the [Erlang-Red](https://github.com/gorenje/erlang-red) project.
 
@@ -38,6 +38,95 @@ This package also defines the following actions that can be mapped to keyboard s
 - Send Halt To Test Server: (Erlang-Red only) restarts the server
 - Run All Tests: (Erlang-Red only) run all defined unit tests.
 
+## Specification of core functionality for Node-RED. 
+
+A collection of nodes also contains a set of flows that represent unit tests that test core functionality of core nodes. 
+
+The intention is to have a set of visual flows that test specific functionality of the Node-RED core nodes. In this package form, tests can be installed in future versions of Node-RED to ensure that functionality is maintained. 
+
+**Why do this?**
+
+Because it provides a method for anyone to create flows to test functionality. As opposed to unit tests and integration tests defined in the project as NodeJS code, this approach, a visual approach allows anyone who has an interest to create mini unit-tests to ensure that the functionality that they expect is maintained in Node-RED.
+
+What is provided is a collection of 200 tests that can be executed via a sidebar plugin. Tests are executed in the background on the server. Existing flows may be affected, so it is best to do this **without** any existing flows defined.
+
+It is intended to be done once, maybe for an initial release of Node-RED. There is no real reason to do this continually. It does provide a way of doing unit tests as well. So the idea is also to provide a mechanism—a visual mechanism—for defining unit tests for other projects as well. Future releases of this package will allow independent collections of unit tests for your own projects.
+
+The aim would be to have a project directory, and within that project directory, there are a set of flows that test specifics of that project. Those tests would then be shown in the plugin on the sidebar, and those tests would then be executed for changes to the project, to the flows, the existing flows. So that's the goal in the long term: to provide a visual unit testing framework for projects. 
+
+So far this is only a demonstration of how to do this for the Node-RED project itself.
+
+## How do the provided unit tests work? 
+
+Each unit test defines one or more inject nodes that are triggered when the test starts. Once the test is started, the assert nodes are triggered and test specific conditions. If any assert node fails, the entire test fails.
+
+Assert nodes can either test that a message arrives or that a message doesn't arrive. The assert false asserts that if a message arrives, it will fail. The assert success node ensures that one or more messages arrive, a limit of messages arrive, or a maximum number of messages arrive. If the assert success node is configured with zero message count, then 1 or more messages are expected.
+
+The assert values node is used to test specific values on the message object and ensure that those are correct. Assert values node fails if values aren't correct or if a message is not received. The assert values node expects at least a single message, multiple messages are tested against the same conditions.
+
+Failures of all assert nodes are shown in the Node-RED console log.
+
+## Configuration via flow environment values
+
+Tests can also be given specific properties via the flow-tab environment variables. Features such as pending tests can be indicated, so that if a test haven’t been completed yet or will fail, tests can be set to pending. 
+
+A test can be given a timeout period, to specify when tests time out. The timeout defaults to 5 seconds, so after a test starts, it has 5 seconds to complete. If it requires longer, then a timeout value of higher than 5 can be given. The timeout values are in seconds, and are provided in the environment values of the flow tab.
+
+## Sidebar Plugin Functionality
+
+The sidebar functionality provides testing features for testing all tests, a subset of tests and a single test. Also tests can be loaded into the editor using a double click on the test name.
+
+Modifications of tests are not stored nor can tests be modified inside the package. Defining your own tests will require creating your own flow files.
+
+## What is correct functionality? 
+
+What do I define as core node functionality? What I mean by that is that things like status and debug messages are also core functionality. So if a node generates a status message, then I want to test that it generates that status message. And if it generates a debug message, then I want to test that it generates that debug message.
+
+That's why the assert status and assert debug nodes in this package - that is what they are testing for. I consider this part of the core functionality, of a core node because folks could rely on that. 
+
+Especially the debug count: when you see how many messages are going through, that could be a very important dependency that might be used for ensuring that flows work correctly, depending on the setup. So, that's why for me, also checking that nodes generate the expected debug message and the expected status messages or status indications is also part of core functionality of core nodes.
+
+## True Negatives and False Positives 
+
+Obviously, the testing is not 100 percent; nothing’s perfect in this world. I have tried my best to get it as accurate as possible, but sometimes because of timing issues with the tests, I do make assumptions about certain things happening in a certain order or taking a certain amount of time. Sometimes these conditions don't hold, and so the test do fail.
+
+I have endeavoured to indicate that on those tests that are potentially not so consistent. However, I haven't obviously covered everything, as it is just a first attempt. There are cases where there are sometimes tests failing, and I have endeavoured to mark those, comment on those, and ensure that you know, to the best of my abilities, I've tried to make these tests as stable and correct as possible.
+
+That includes making certain assumptions about functionality that might not actually be correct, as there is no written-down standardised functionality for Node-RED. Sometimes I might even be testing functionality that isn't actually meant to be correct.
+
+However, that is the intention of this package: it is also to define those things and make that clearer—what is functionality and what isn't. That is, I think, part of this project: to define that a little bit more clearly.
+
+## Incomplete implementation
+
+The assert values node isn't completely implemented; certain values aren't supported. The assert debug and the assert status nodes don't work either; they aren't supported yet.
+
+What this package doesn't provide, unfortunately, are the two assert nodes related to status and debug. So these nodes are designed to capture any debug messages sent by a node or any status generated by the node. 
+
+So this is partly, obviously, for the status. One can use the status node itself, but it's difficult to test the status node if you're using the status node. So that's why there's an assert status node and the assert debug cannot be replaced by anything else because there's no way in Node-RED to capture the debug output generated by a node. 
+
+The unfortunate thing is then it's hard to test the output generated by nodes. That meaning debug messages or status messages to ensure that there's actually something generated. This is also part of the functionality of Node-RED. So I see that if a node generates a status message, then that should be tested for. If a node generates a debug message, then that should be tested for. So that's what these debug nodes, assert debug and assert status are meant to be doing. 
+
+But they are unfortunately not implementable for Node-RED because there's no way of adding hooks to these messages. Or at least none that I found.
+
+## Discussion: why is this important enough for me?
+
+Why do I see this standardisation as important? Obviously, I've invested quite a bit of time into making these tests and creating this package. Why do I think that's so important? There are a couple of reasons.
+
+One is that I see this as a way of ensuring that there's a benchmark for Node-RED functionality. So you say, okay, the complete node does just this, completes, and the change node can do this, this, and this, and it can only do that. That's then well-defined as a test or a series of tests to say, "Okay, this is what it has to be doing”. With that, it is clear: okay, this is within the bounds of the change node, and this is not within the bounds of the change nodes. Then a discussion can be started to say whether the bounds of the change node should be extended, or whether a new node should be defined for some specific functionality. So that's one thing I think is important: to define clearly what core nodes do and, equally important, what they will not do - the boundary of their functionality.
+
+In a [long discussion](https://discourse.nodered.org/t/brittle-flows-or-is-it-the-visual-paradigm/100911/30) with Nick, it became clear that there is no such standardisation or definition for the functionality of nodes. It's kind of like whatever feels good and feels right, a "will do" type of decision-making, which is fine, and I'm not criticising that. My second point is to say, okay, well, for industry applications and for industries which are based on standards, it could be important to say, okay, well, if we're going to use Node-RED, then we want to know that version X of Node-RED will be doing the same thing as version Y down the road. And this kind of node package, this unit testing of the functionality, can be a guarantee of that consistency into the future. 
+
+Thirdly, it could also show when there's a divergence of functionality. And this makes upgrading versions of Node-RED for an industry application safer. That's another thing that I see could be useful for this package.
+
+The final point that I see is also the origins of this entire project: compatibility testing. So, having created Erlang-RED, which is the Erlang-backed Node-RED (the Node-RED frontend editor with an Erlang backend), I was kind of interested in how do I define the functionality of the nodes. How do I know that my nodes are working correctly according to what Node-RED is doing? Because I want to do want to have 100% compatibility with Node-RED flows. Why do I want that? It's because I want to be able to take in a visual abstraction, a Node-RED flow, and have it run as Erlang code, or as NodeJS code, or Python code, or whatever code. So that the visualisation, the visual flow representation, becomes an abstraction between different programming languages.
+
+Therefore, to be able to do that, to be able to port flows one-to-one to Erlang-RED, I need to be able to ensure that the Erlang-RED nodes are doing what the Node-RED nodes are doing. And so that's why I started creating these unit tests, which run both in Erlang-RED and in Node-RED. So this Node package I actually use for Erlang-RED as well, with a slightly modified set of tests than the ones defined here.
+
+## Forum Discussions
+
+- [Standardisation of core functionality - May 2026](https://discourse.nodered.org/t/brittle-flows-or-is-it-the-visual-paradigm/100911)
+- [Flow testsuite for testing core node functionality - May 2025](https://discourse.nodered.org/t/flow-testsuite-for-testing-core-node-functionality/97106)
+
 ## Tee Time
 
 <a href="https://www.buymeacoffee.com/gorenje" target="_blank"><img src="https://cdn.buymeacoffee.com/buttons/v2/default-red.png" alt="Buy Me A Tee" style="height: 42px !important;width: 152px !important;" ></a>

package/nodes/locales/en-US/ut-assert-success.html

@@ -1,6 +1,12 @@
 <script type="text/html" data-help-name="ut-assert-success">
-  <p>This node failes if, during flow execution, it is not reached.</p>
-  A success assertion meaning that this node **must** be reached when a flow is executed as part of a test.
+<p>This node failes if, during flow execution, it is not reached.</p>
+A success assertion meaning that this node <b>must</b> be reached when a flow is executed as part of a test.
 
+<p>
 If this node isn't reached, then the test will fail.
+</p>
+
+<p>
+A message count of zero is assumed to be <b>at least one message</b>, it's the same as minimum of one message.
+</p>
 </script>

package/nodes/locales/en-US/ut-assert-success.json

@@ -7,7 +7,13 @@
       "succeed": "assert succeed",
       "count": "Msg Count",
       "unsupported": "Unsupported",
-      "failed": "assert failed"
+      "failed": "assert failed",
+      "messages": "Msgs",
+      "limit": {
+        "upperlimit" : "Max",
+        "exactly": "Exactly",
+        "lowerlimit": "Min"
+      }
     },
 
     "status": {

package/nodes/ut-assert-debug.js

@@ -5,8 +5,17 @@ module.exports = function(RED) {
     var node = this;
     var cfg = config;
 
-    node.on('close', function() {
-      node.status({});
+    node.on('close', function (removed, done) {
+      if (removed) {
+        node.status({});
+      } else {
+        // use node.log(..) here because node.error(..) sends a message to the debug
+        // panel but that errors out because the frontend can't find the workspace:
+        //    Uncaught TypeError: can't access property "label", RED.nodes.workspace(...) is undefined
+        // that has follow-on effects.
+        node.log(`UNSUPPORTED [${node.z}] debug is not supported`)
+      }
+      done()
     });
 
     /* msg handler, in this case pass the message on unchanged */
@@ -36,4 +45,378 @@ module.exports = function(RED) {
 
   RED.nodes.registerType("ut-assert-debug", Coreut_assert_debugFunctionality);
 
+  // Backend endpoints
+RED.httpAdmin.get("/UnitTesting/:flowid/runtest",
+  (req, res) => {
+    const path = require('path');
+    const fs = require('fs')
+    const jsonClone = require("rfdc")();
+    
+    // API defined here --> https://github.com/node-red/node-red/blob/master/packages/node_modules/%40node-red/runtime/lib/index.js
+    const runtime = require("@node-red/runtime");
+
+    let testDir = path.resolve(path.dirname(__filename), "..", "testflows")
+
+    // if a test generates an uncaught exception, then captcha that and generate
+// a failure - tests are considered failed if they generate uncaught exceptions/errors.
+let createExtraCatchNode = () => {
+  let changeId = runtime.util.generateId()
+  let assertId = runtime.util.generateId()
+  let debugId = runtime.util.generateId()
+
+  return [
+    {
+      "id": runtime.util.generateId(),
+      "type": "catch",
+      "name": "",
+      "scope": null,
+      "uncaught": true,
+      "wires": [
+        [
+          changeId
+        ]
+      ]
+    },
+    {
+      "id": changeId,
+      "type": "change",
+      "name": "",
+      "rules": [
+        {
+          "t": "set",
+          "p": "_unittest_triggered",
+          "pt": "msg",
+          "to": "true",
+          "tot": "bool"
+        }
+      ],
+      "action": "",
+      "property": "",
+      "from": "",
+      "to": "",
+      "reg": false,
+      "wires": [
+        [
+          assertId,
+          debugId
+        ]
+      ]
+    },
+    {
+      "id": debugId,
+      "type": "debug",
+      "name": "",
+      "active": true,
+      "tosidebar": false,
+      "console": true,
+      "tostatus": false,
+      "complete": "payload",
+      "targetType": "msg",
+      "statusVal": "",
+      "statusType": "auto",
+      "wires": []
+    },
+    {
+      "id": assertId,
+      "type": "ut-assert-failure",
+      "name": "",
+      "wires": []
+    }
+  ]
+}
+
+let isTestPending = (tabDetails) => {
+  return tabDetails.env.filter(d => d.name == "NRED_PENDING")[0]?.value == "true"
+}
+
+// chunkify an array into chunks of `size` size
+let chunkify = (array, size) => {
+  const chunkedArray = [];
+  for (let i = 0; i < array.length; i += size) {
+    chunkedArray.push(array.slice(i, i + size));
+  }
+  return chunkedArray;
+}
+
+// respond to request with a list of total tests to be done. The frontend then
+// shows a progress indication of success / pending / failure
+let respondWithCount = (res, count) => {
+  res.writeHead(200, { 'Content-Type': 'application/json' });
+  res.end(JSON.stringify({ status: "ok", todo: count }));
+}
+
+
+    if (req.params.flowid == "all") {
+      //
+      // Run all tests. This is a little more complicated as this runs all tests in batches
+      // of ten tests at a time but these have to be added in serial and also removed in 
+      // serial, so there has to be promise handling ... and that makes this stuff a little
+      // more complicated.
+      //
+
+      let allTests = fs.globSync(`${testDir}/**/*.json`)
+
+      // if a limit (i.e. a list of testFlow ids) is provided, only peform those tests.
+      if (req.query.limit) {
+        let testIds = req.query.limit.split(",")
+
+        allTests = allTests.filter( filename => {
+          let origFlowId = path.basename(path.parse(filename).dir)
+          return testIds.indexOf(origFlowId) > -1
+        })
+      }
+
+      let chunkedFilenames = chunkify(allTests, 10)
+
+      respondWithCount(res, allTests.length)
+
+      let runTestsForFileNames = (fileIdx) => {
+        if (fileIdx >= chunkedFilenames.length) { return }
+
+        // test all is a multi step process, first we have to add all flows to the main show
+        // then we have to trigger them and finally we have to remove those that weren't
+        // there in the first place.
+        let flowIdsToBeRemoved = []
+        let injNodesToBeTriggered = {}
+
+        let timeoutValues = []
+
+        let flowsToAdd = chunkedFilenames[fileIdx].map((filename) => {
+          
+          let origFlowId = path.basename(path.parse(filename).dir)
+
+          let flowDetails = JSON.parse(fs.readFileSync(filename))
+          let tabDetails = flowDetails.filter(d => d.type == "tab")[0]
+          let injNodesIds = flowDetails.filter(d => d.type == "inject").map(d => d.id)
+          
+          RED.log.debug(`unittest: adding test case [${origFlowId}] - '${tabDetails.label}'`)
+
+          if (isTestPending(tabDetails) && req.query["testpend"] != "true") {
+            RED.comms.publish("unittesting:testresults", {
+              flowid: origFlowId,
+              status: "pending"
+            })
+            return null
+          }
+
+          // compute any timeout that is defined for the flow test
+          tabDetails.env.filter(d => d.name == "NRED_TIMEOUT").forEach( d => {
+            timeoutValues.push(parseInt(d.value) * 1000)
+          })
+
+          // add an catch all and trigger a assert false if any exceptions are
+          // raised by the test - if there isn't already a catch all node.
+          if (flowDetails.filter(d => d.type == "catch").filter(d => d.scope == null).length == 0) {
+            flowDetails = flowDetails.concat(createExtraCatchNode())
+          }
+
+          if (runtime._.flows.getFlow(origFlowId)) {
+            injNodesToBeTriggered[origFlowId] = injNodesIds.map(d => d)
+            return null
+          } else {
+            return {
+              injNodesIds: injNodesIds, origFlowId: origFlowId, nodes: flowDetails
+            }
+          }
+        }).filter(d => !!d)
+
+        // addFlow is a promise but I want to add flows in series not parallel, so the
+        // promise returns a promise that adds the next flow after the initial flow
+        // has been added. It's promises all the way down - until the turtles start.
+        let addFlow = (idx) => {
+          if (idx >= flowsToAdd.length) { return }
+          var { injNodesIds, origFlowId, nodes } = flowsToAdd[idx]
+
+          var newConfig = jsonClone(runtime._.flows.getFlows().flows);
+          newConfig = newConfig.concat(nodes);
+
+          return runtime._.flows.setFlows(newConfig, null, 'flows', false, null, "root")
+            .then(() => {
+              let newFlowId = origFlowId
+              injNodesToBeTriggered[newFlowId] = injNodesIds.map(d => d)
+              flowIdsToBeRemoved.push(newFlowId)
+            })
+            .catch(e => { RED.log.error(e); RED.log.error(`Exception happened with ${origFlowId}`) })
+            .finally(() => addFlow(idx + 1))
+        }
+
+        Promise.all([addFlow(0)]).then(() => {
+          RED.log.debug("unittest: done adding all flows")
+
+          runtime._.flows.startFlows("full", null, false, true).then(d => {
+            Object.keys(injNodesToBeTriggered).forEach(flowId => {
+              injNodesToBeTriggered[flowId].forEach(ndeId => {
+                RED.log.debug(`unittest: triggering inject node: ${ndeId}`)
+                RED.nodes.getNode(ndeId)?.receive({"_unittest_triggered": true})
+              })
+            })
+
+            let removeFlow = (idx) => {
+              if (idx >= flowIdsToBeRemoved.length) { return }
+              let flowid = flowIdsToBeRemoved[idx]
+
+              return runtime._.flows.removeFlow(flowid, "root")
+                .then((_ignore) => {
+                  RED.comms.publish("unittesting:testresults", {
+                    flowid: flowid,
+                    status: "stopped"
+                  })
+                })
+                .catch(e => {
+                  RED.log.error(e);
+                  RED.log.error(`Error happened removing flow ${flowid}`)
+                  RED.comms.publish("unittesting:testresults", {
+                    flowid: flowid,
+                    status: "stopped"
+                  })
+                })
+                .finally(() => removeFlow(idx + 1))
+            }
+
+            setTimeout(() => {
+              Promise.all([removeFlow(0)]).then(() => {
+                RED.log.debug("unittest: removed all flows")
+                runTestsForFileNames(fileIdx+1)
+              })
+            }, Math.max(...(timeoutValues.concat([5000]))))
+          })
+        })
+      }
+      runTestsForFileNames(0)
+    } else {
+
+      //
+      // run a single unit test but ensure that the test case does exist on disk
+      //
+
+      respondWithCount(res, 1)
+
+      fs.globSync(`${testDir}/**/*.json`).filter(d => d.includes(req.params.flowid)).forEach(filename => {
+        let flowDetails = JSON.parse(fs.readFileSync(filename))
+        let origFlowId = req.params.flowid
+
+        let tabDetails = flowDetails.filter(d => d.type == "tab")[0]
+        let injNodesIds = flowDetails.filter(d => d.type == "inject").map(d => d.id)
+
+        let timeoutValues = []
+
+        if (isTestPending(tabDetails) && req.query["testpend"] != "true") {
+          RED.comms.publish("unittesting:testresults", {
+            flowid: origFlowId,
+            status: "pending"
+          })
+          return null
+        }
+
+        // compute any timeout that is defined for the flow test
+        tabDetails.env.filter(d => d.name == "NRED_TIMEOUT").forEach(d => {
+          timeoutValues.push(parseInt(d.value) * 1000)
+        })
+        
+        // add an catch all and trigger a assert false if any exceptions are
+        // raised by the test - if there isn't already a catch all node.
+        if (flowDetails.filter(d => d.type == "catch").filter(d => d.scope == null).length == 0) {
+          flowDetails = flowDetails.concat(createExtraCatchNode())
+        }
+
+        // if flow already exists, then just trigger the inject nodes
+        if (runtime._.flows.getFlow(origFlowId)) {
+          setTimeout(() => {
+            injNodesIds.forEach(ndeId => {
+              RED.nodes.getNode(ndeId)?.receive({"_unittest_triggered": true})
+            })
+          }, 500)
+
+          setTimeout(() => {
+            // tell the frontend that we've done with the test. If no 
+            // status has been posted for the unit test, then it succeeds.                
+            RED.comms.publish("unittesting:testresults", {
+              flowid: origFlowId,
+              status: "stopped"
+            })
+          }, Math.max(...(timeoutValues.concat([5000]))))
+        } else {
+          var newConfig = jsonClone(runtime._.flows.getFlows().flows);
+          newConfig = newConfig.concat(flowDetails);
+
+          runtime._.flows.setFlows(newConfig, null, 'flows', false, null, "root").then(() => {
+            runtime._.flows.startFlows("full", null, false, true).then(d => {
+              setTimeout(() => {
+                injNodesIds.forEach(ndeId => {
+                  RED.nodes.getNode(ndeId)?.receive({"_unittest_triggered": true})
+                })
+              }, 500)
+
+              setTimeout(() => {
+                runtime._.flows.removeFlow(origFlowId, "root").then(result => {
+                  // tell the frontend that we've done with the test. If no 
+                  // status has been posted for the unit test, then it succeeds.                
+                  RED.comms.publish("unittesting:testresults", {
+                    flowid: origFlowId,
+                    status: "stopped"
+                  })
+                })
+              }, Math.max(...(timeoutValues.concat([5000]))))
+            })
+          })
+        }
+      })
+    }
+  });
+
+RED.httpAdmin.get("/UnitTesting/halt",
+  (req, res) => {
+    var runtime = require("@node-red/runtime");
+    runtime._.flows.stopFlows()
+    res.sendStatus(200);
+  });
+
+RED.httpAdmin.get("/UnitTesting/:flowid/retrieve",
+  (req, res) => {
+    const path = require('path');
+    const fs = require('fs')
+
+    let fileName = path.resolve(path.dirname(__filename), "..", "testflows", req.params.flowid, "flows.json")
+    const data = fs.readFileSync(fileName);
+
+    try {
+      res.writeHead(200, { 'Content-Type': 'application/json' });
+      res.end(JSON.stringify({ flowdata: JSON.parse(data) }));
+    } catch (err) {
+      res.sendStatus(500);
+    }
+  });
+
+RED.httpAdmin.get("/UnitTesting/tests.json",
+  (req, res) => {
+    let testData = {
+      "status": "ok",
+      "last_updated_at": "2025-04-09T14:54:01.665Z",
+      "data": {
+      }
+    }
+
+    const path = require('path');
+    const fs = require('fs')
+
+    let testDir = path.resolve(path.dirname(__filename), "..", "testflows")
+
+    fs.globSync(`${testDir}/**/*.json`).forEach(filename => {
+      let details = path.parse(filename)
+      const data = fs.readFileSync(filename);
+
+      testData.data[path.basename(details.dir)] = {
+        "id": path.basename(details.dir),
+        "name": JSON.parse(data).filter(d => d.type == "tab")[0].label
+      }
+    })
+
+    try {
+      res.writeHead(200, { 'Content-Type': 'application/json' });
+      res.end(JSON.stringify(testData));
+    } catch (err) {
+      res.sendStatus(500);
+    }
+  });
+
 }

package/nodes/ut-assert-failure.js

@@ -1,35 +1,46 @@
-module.exports = function(RED) {
+module.exports = function (RED) {
   function CoreutassertfailureFunctionality(config) {
-    RED.nodes.createNode(this,config);
+    RED.nodes.createNode(this, config);
 
     var node = this;
     var cfg = config;
 
-    node.on('close', function() {
+    node.on('close', function () {
       node.status({});
     });
 
     /* msg handler, in this case pass the message on unchanged */
-    node.on("input", function(msg, send, done) {
+    node.on("input", function (msg, send, done) {
 
-       node.status({ fill: "red", shape: "dot", text: RED._("ut-assert-failure.label.failed") });
+      RED.comms.publish("unittesting:testresults", {
+        flowid: node.z,
+        status: "failed"
+      })
 
-        // Send a message and how to handle errors.
+      // use node.log(..) here because node.error(..) sends a message to the debug
+      // panel but that errors out because the frontend can't find the workspace:
+      //    Uncaught TypeError: can't access property "label", RED.nodes.workspace(...) is undefined
+      // that has follow-on effects.
+      // see https://nodered.org/docs/creating-nodes/node-js#logging-events for more details
+      node.log(`FAILED [${node.z}] assert failure was sent a message`, msg)
+      node.status({ fill: "red", shape: "dot", text: RED._("ut-assert-failure.label.failed") });
+
+      // Send a message and how to handle errors.
+      try {
         try {
-          try {
-            send(msg);
-            done();
-          } catch ( err ) {
-            // use node.error if the node might send subsequent messages
-            node.error("error occurred", { ...msg, error: err })
-            done();
-          }
+          send(msg);
+          done();
         } catch (err) {
-          // use done if the node won't send anymore messages for the
-          // message it received.
-          msg.error = err
-          done(err.message, msg)
+          // use node.error if the node might send subsequent messages
+          node.error("error occurred", { ...msg, error: err })
+          done();
         }
+      } catch (err) {
+        // use done if the node won't send anymore messages for the
+        // message it received.
+        msg.error = err
+        done(err.message, msg)
+      }
     });
   }
 

package/nodes/ut-assert-status.js

@@ -5,8 +5,17 @@ module.exports = function(RED) {
     var node = this;
     var cfg = config;
 
-    node.on('close', function() {
-      node.status({});
+    node.on('close', function(removed, done) {
+      if ( removed) {
+        node.status({});
+      } else {
+        // use node.log(..) here because node.error(..) sends a message to the debug
+        // panel but that errors out because the frontend can't find the workspace:
+        //    Uncaught TypeError: can't access property "label", RED.nodes.workspace(...) is undefined
+        // that has follow-on effects.
+        node.log(`UNSUPPORTED [${node.z}] status is not supported`)
+      }
+      done()
     });
 
     /* msg handler, in this case pass the message on unchanged */